A semantic table for presenting tabular data.

If you just want to represent static data then the rx.data_table might be a better fit for your use case as it comes with in-built pagination, search and sorting.

Many times there is a need for the data we represent in our table to be dynamic. Dynamic data must be in State. Later we will show an example of how to access data from a database and how to load data from a source file.

In this example there is a people data structure in State that is iterated through using rx.foreach.

It is also possible to define a class such as Person below and then iterate through this data structure, as a list[Person].

In this example we sort and filter the data.

The state variable _people is set to be a backend-only variable. This is done incase the variable is very large in order to reduce network traffic and improve performance.

For sorting the rx.select component is used. The data is sorted based on the attributes of the Person class. When a select item is selected, as the on_change event trigger is hooked up to the set_sort_value event handler, the data is sorted based on the state variable sort_value attribute selected. (Every base var has a built-in event handler to set it's value for convenience, called set_VARNAME.)

For filtering the rx.input component is used. The data is filtered based on the search query entered into the rx.input component. When a search query is entered, as the on_change event trigger is hooked up to the set_search_value event handler, the data is filtered based on if the state variable search_value is present in any of the data in that specific Person.

current_people is an rx.var(cache=True). It is a var that is only recomputed when the other state vars it depends on change. This is to ensure that the People shown in the table are always up to date whenever they are searched or sorted.

The more common use case for building an rx.table is to use data from a database.

The code below shows how to load data from a database and place it in an rx.table.

A Customer model is defined that inherits from rx.Model.

The load_entries event handler executes a query that is used to request information from a database table. This load_entries event handler is called on the on_mount event trigger of the rx.table.root.

If you want to load the data when the page in the app loads you can set on_load in app.add_page() to equal this event handler, like app.add_page(page_name, on_load=State.load_entries).

In this example we sort and filter the data.

For sorting the rx.select component is used. The data is sorted based on the attributes of the Customer class. When a select item is selected, as the on_change event trigger is hooked up to the sort_values event handler, the data is sorted based on the state variable sort_value attribute selected.

The sorting query gets the sort_column based on the state variable sort_value, it gets the order using the asc function from sql and finally uses the order_by function.

For filtering the rx.input component is used. The data is filtered based on the search query entered into the rx.input component. When a search query is entered, as the on_change event trigger is hooked up to the filter_values event handler, the data is filtered based on if the state variable search_value is present in any of the data in that specific Customer.

The % character before and after search_value makes it a wildcard pattern that matches any sequence of characters before or after the search_value. query.where(...) modifies the existing query to include a filtering condition. The or_ operator is a logical OR operator that combines multiple conditions. The query will return results that match any of these conditions. Customer.name.ilike(search_value) checks if the name column of the Customer table matches the search_value pattern in a case-insensitive manner (ilike stands for "case-insensitive like").

Pagination is an important part of database management, especially when working with large datasets. It helps in enabling efficient data retrieval by breaking down results into manageable loads.

The purpose of this code is to retrieve a specific subset of rows from the Customer table based on the specified pagination parameters offset and limit.

query.offset(self.offset) modifies the query to skip a certain number of rows before returning the results. The number of rows to skip is specified by self.offset.

query.limit(self.limit) modifies the query to limit the number of rows returned. The maximum number of rows to return is specified by self.limit.

The real power of the rx.table comes where you are able to visualise, add and edit data live in your app. Check out these apps and code to see how this is done: app: https://customer-data-app.reflex.run code: https://github.com/reflex-dev/reflex-examples/tree/main/customer_data_app and code: https://github.com/reflex-dev/data-viewer.

Most users will want to download their data after they have got the subset that they would like in their table.

In this example there are buttons to download the data as a json and as a csv.

For the json download the rx.download is in the frontend code attached to the on_click event trigger for the button. This works because if the Var is not already a string, it will be converted to a string using JSON.stringify.

For the csv download the rx.download is in the backend code as an event_handler download_csv_data. There is also a helper function _convert_to_csv that converts the data in self.users to csv format.