Create form automatically from a given query

[apedroferreira]

Duplicates

• [X] I have searched the existing issues

Latest version

• [X] I have tested the latest version

Summary 💡

It should be possible to automatically generate a form for a given, already defined query. The form would use the parameters of the query to determine which fields to include and which type those fields should be. Submitting the form would call the given query with the respective form values for the parameters. The form should always stay in sync with the query if the query changes.

This could be implemented as a separate "server form" component if it does not fit well into the drag-and-drop form component we're planning to add in https://github.com/mui/mui-toolpad/issues/749.

Another possible (later) improvement to this concept that might deserve its own issue: automatically creating a form for a given collection (once we have the concept of a server-side data collection).

Benchmarks 🌈

https://docs.plasmic.app/learn/forms/ Retool:

https://github.com/mui/mui-toolpad/assets/92228082/4ba0c049-cd43-4645-9e1a-322f70883392

[Janpot]

Some of the use cases I see where Toolpad forms fall short, these can't necessarily be solved by 1 single form component:

1. Generating a form from a programatic definition (e.g. json schema). Where one can use a jsonschema copied/linked from openapi, all set up with validation, or where we can couple it to a datagrid.
2. Field validation: required, email, url, regex, number range, date range, length,...
3. Encapsulation. When you look at a form as a composition of controlled components. It itself being a controlled component. Why can I bind fields in a form to anything other than the value that is being controlled by the form? It would be better if each component under a form declares a "field", and that field is the property that gets read/written on the form value. A nested form similarly has a "field" property and behaves just like any other controlled component.
4. UI: separate labels, alignment, sections, multiple columns,...

[apedroferreira]

Some of the use cases I see where Toolpad forms fall short, these can't necessarily be solved by 1 single form component:

1. Generating a form from a programatic definition (e.g. json schema). Where one can use a jsonschema copied/linked from openapi, all set up with validation, or where we can couple it to a datagrid.
2. Field validation: required, email, url, regex, number range, date range, length,...
3. Encapsulation. When you look at a form as a composition of controlled components. It itself being a controlled component. Why can I bind fields in a form to anything other than the value that is being controlled by the form? It would be better if each component under a form declares a "field", and that field is the property that gets read/written on the form value. A nested form similarly has a "field" property and behaves just like any other controlled component.
4. UI: separate labels, alignment, sections, multiple columns,...

Those are fair points, the first implementation of the Form component was just a first approach, based on solutions like Retool's and considering that we would have more feedback afterwards. I feel like all of these could be worked on as separate features, as they all would need some conceptualization of how we should make things work. I don't fully understand item 3 and how it would compare to the current solution, so we can probably discuss it more later and make it clearer and more concrete. But I understand that it would probably fit better into some kind of "form definition" that we could use for item 1 too.