Frontend: Should we mimic the antd ProTable component configuration?

[MrSnyder]

After going through the current tasks (#269, #271, #272, #273) for improving the generic ResourceTable component, I came to the conclusion that it is a good idea to provide convenient defaults (e.g. for columns, rendering of columns, filtering), but still allow everything to be overwritten if required. IMHO, this is important as it allows the new component to be used without sacrificing flexibility whenever we need it.

Basically, every option that is provided by the basic antd table component should be available in ResourceTable, but it should add automatic configuration based on the backend resource schema. AFAIK, this is the exact approach that the antd ProTable follows. It claims to make CRUD-workflows very easy without configuration, but keeps the configurability of the original antd table component.

I believe we should check how the configuration of the antd ProTable component works and decide if we should mimic the concepts or simply use the pro component in MrMap.

[MrSnyder]

As evaluated in #281 and discussed in the developer meeting today, we will go with the antd ProTable for now, as it offers some benefits for our use cases:

• Built-in support for backend sorting, filtering and pagination
• Built-in support for reload and interactive column selection
• Built-in support for an automatically generated query form
• Concepts for batch operations
• Seems to fit nicely with our schema-driven approach
• Support for data type and locale based rendering (e.g. dates)

We will still need to extend upon this component:

• Derive the table column definitions from the OpenAPI schema in a robust way
• Apply the filtering capabilities reported by the backend to the query form
• Enable easy-support for custom actions

Also, it is not 100% clear yet if the fact that the antd ProComponents are built on top of UmiJS will result in any issues for our architecture, as the technical implications are not fully clear yet. Some possible areas:

• i18n is implemented in a specific way (handled by a UmiJS-plugin)
• There seems to be a tendency for the antd ProComponents to favor backend configuration, e.g. for the ProLayout