A high-level data table with backend pagination that includes business query conditions, data addition, deletion, modification, and query, and dynamically renders operation buttons based on permissions

[jinhong-china]

Create a data table directly using the following code

async def render_apilog():
    with ui.column():

        # 创建表格所需的后端数据源配置,分贝对应CRUD的四种方式
        crud_source = {
            # "init_source":crud_apilog_init,
            "create_source":crud_apilog_create,
            "read_source":crud_apilog_read,
            "update_source":crud_apilog_update,
            "delete_source":crud_apilog_delete
        }

        # 分页模式,默认后端分页
        pagination_type = "backend"

        # 表格列的别名,如果有的话
        column_names = {
            "phone":"手机号",
            "client_ip":"IP地址",
            "request_method":"请求方式",
            "response_ms":"请求耗时",
            "creator_id":"创建者",
            "x_call_source":"请求来源",
            "status_code":"状态码"
        }

        # 初始化并创建表格
        table = CustomDataTable()
        await table.create(
            crud_source=crud_source,        # 后端的数据源函数
            pagination_type=pagination_type,        # 分页模式
            perpage=20,                             # 每页数据量
            column_names=column_names               # 表格列别名
            )

Let me first explain the functions of this table:

1. If pagination_type="frontend" is explicitly specified in table.create, it is frontend paging We are using the official default form
2. Complete functionality requires backend collaboration. I can only explain what the backend needs to pay attention to. After all, people who like Nicegui are good at Python backend
3. The default is backend pagination, with 20 data entries per page. If you want to modify it, you can modify the value of the perpage in the above code The backend data return needs to include three key values: total, page, and data (specific data), and the page number and page button will be automatically calculated at the bottom of the page
4. Four crud functions, except for delete which passes an int, the other three pass a dictionary as a parameter, and the corresponding backend interface functions are received using * * kwargs

# 后端接口的crud函数,可以根据实际情况自定义编写.
async def crud_apilog_read(**kwargs):
	pass
	
async def crud_apilog_create(**kwargs):
	pass

async def crud_apilog_update(**kwargs):
	pass

async def crud_apilog_delete(data_id:int):
	pass

5. Automatically render query conditions based on the obtained data, which can be expanded or contracted by clicking You can input query criteria to retrieve data If the total number of data pages is 50, the current pagination has already reached 40 After entering the query criteria, if the amount of data that meets the criteria is relatively small, with only 10 pages, the current page count will automatically become 10. Alternatively, you can specify the query criteria to locate the first page, and the backend needs to set the returned page value to 1
6. The crud_apilog.read function in the backend needs to include both conditional and unconditional queries Just need to judge based on the key value pairs contained in * * kwagrs The main thing to note is that when querying the database, it is necessary to exclude the three fixed parameters of page, perpage, and pagination_tpye from kwagrs Because regardless of whether there are front-end business query conditions, there will always be these three query conditions to meet the needs of back-end pagination
7. There is a display/hide column switch in the upper right corner of the table, which uses the official native method and only hides the frontend rendering
8. The data table will read the user ID from app. storage. tab ["me"] ["id"], and the fields in the data table also need to have a creator_id to determine whether to render the edit button and delete button based on whether they are equal The corresponding logic in business is that only data created by oneself has editing and deleting permissions, otherwise only viewing permissions are granted To correctly render the buttons in the operation column, it is important to match the tab storage, or you can modify the source code yourself
9. Clicking on the previous page when the bottom page is on the first page will prompt an error, and clicking on the next page when it is on the last page will also prompt an error The number of page numbers entered for redirection cannot exceed the maximum number of pages
10. The column_name parameter in 10.table.create is optional, and the key name corresponds to the field name of the data table. The key value is the name that needs to be converted for display. For example, in the above example, the English fields in the API log are converted to Chinese for display when rendering the data table

The original intention of developing this advanced data table is that the official components are too basic, and the actual project requires a much richer functionality of the data table For example, batch editing and deletion functions, export and import functions, and so on may also be required For the convenience of future development, I have encapsulated this advanced data table, and all functions are implemented based on the native methods of Nicegui I don't know if the official plan is to develop advanced data table components like this If you are interested in my job, can I create a PR?

[falkoschindler]

Hi @jinhong-china, thank you for sharing this feature request!

I have a few thoughts on this proposal:

Clarity of the request

The current description is quite broad and combines multiple complex features (backend pagination, CRUD operations, permission-based UI rendering, business query conditions). To better evaluate this, it would help to have:

• A clearer breakdown of the specific requirements
• Examples of the API you envision
• Use cases that demonstrate why this needs to be in NiceGUI core vs. built on top of existing elements

Viability assessment

Whether this fits into NiceGUI core depends heavily on the actual implementation. NiceGUI follows a philosophy of simplicity and keeping the core library focused on fundamental UI building blocks. A high-level data table component with business logic integration would need to:

• Maintain backward compatibility with existing ui.table functionality
• Avoid adding unnecessary dependencies
• Provide a clean, simple API that aligns with NiceGUI's design principles
• Be general enough to serve diverse use cases without becoming overly complex

Without seeing a concrete implementation, it's difficult to assess whether this would fit well into the core library or if it would add too much complexity.

Alternative approach

Given the scope and business-logic-specific nature of this feature, it might be better suited as a separate package that builds on top of NiceGUI. This approach has several advantages:

• Faster iteration and development without core API stability constraints
• Ability to include opinionated defaults and business logic patterns
• Easier to maintain and evolve based on specific use cases
• Can be published as nicegui-data-table or similar, making it discoverable while keeping it optional

If you're interested in pursuing this, I'd suggest:

1. Creating a proof-of-concept implementation in a separate repository
2. Sharing it with the community to gather feedback
3. If it proves valuable and general enough, we can discuss integration into core

If you're interested in pursuing this as a separate package, I'm sure the community will help if there's demand for such a solution.

[jinhong-china]

Thank you for your suggestion