Modal form framework

[SchrodingersGat]

reimplement the existing "API forms" framework in react

Tasks

Beta Give feedback

1. Add framework for launching and rendering modal
2. Implement permission checks
3. Extract form data from API OPTIONS endpoint
4. Extract existing model data from API before rendering
5. Implement "string" input
6. Implement "number" input
7. Implement "select" (choice) input
8. Implement "date" input
9. Implement "API select" input
10. Implement "boolean" input
11. Allow icons to be added to fields
12. Validation based on metadata provided via API
13. Implement onChange callback
14. Handle form submission errors
15. Handle "processing" / "loading" states
16. Custom cancel / submit text
17. Handle initial value for related model fields
18. Implement custom render functions for related model fields
19. Handle "onSuccess" callback - redirect or reload, etc
20. Handle non-field errors
21. Handle file upload / image upload
22. Implement "adjustFilters" callback for related model fields
23. Allow form data to be passed separately to form (e.g. to "duplicate" and edit an existing item)
24. Custom validation types (min / max / length / etc)
25. Implement "datetime" input
26. Handle different form upload modes (get / post / patch / delete)
27. Implement "persistent" dialogs which remain after submission
28. Handle creation of secondary modals
29. allow "focus field" to be specified (or select first field)
30. Support "groups" within each form
31. Support "auto fill" for related fields with only one available item
32. Make "footer" (buttons etc) stick to the bottom of the modal (no scroll) - https://github.com/orgs/mantinedev/discussions/1141

[wolflu05]

I would like to extend this a bit:

• Add sub forms
• Add a generic ApiView to the backend with some typing so the we can easily define such forms
• Dependent settings
• Input type: array list
• Input Type: Date, time, datetime
• validations: int, min, max, regex, ...

[SchrodingersGat]

I would like to extend this a bit:

• Add sub forms - like, secondary forms which open from the first one?
• Add a generic ApiView to the backend with some typing so the we can easily define such forms - example?
• Dependent settings - example?
• Input type: array list - example?
• Input Type: Date, time, datetime
• validations: int, min, max, regex, ...

[wolflu05]

Sub forms

They are an array of other form definitions that are rendered indented. Maybe also collapsable if they want to.

Generic Django Views

I tried to provide the idea a bit in #5295 . If I want to have a form defined from the backend I currently have no type hints and generic views to do so, I need to implement them again and again. I imagine having a View where I can define the form inputs somewhere in the class or via a getter and this view automatically handles advertisement via OPTIONS and calls a function like formSubmit. It should also handle api choices fields.

Dependent settings

This is for choices fields. Sometimes one choice field needs the value of other fields to calculate the choices. E.g. useful for providing the machine first and then conditionally get the specific machines printing form.

Array list

Just an input to provide a list. You start with one input, then there is a button + where you can add some inputs and each input has a delete button to remove it.

[SchrodingersGat]

If I want to have a form defined from the backend I currently have no type hints and generic views to do so, I need to implement them again and again.

Use either a DRF serializer or Django model, and it will be taken care of for you. Check out metadata.py - this is where most of the magic happens. All of the current "front end" forms are constructed from that data.

[SchrodingersGat]

This is for choices fields. Sometimes one choice field needs the value of other fields to calculate the choices. E.g. useful for providing the machine first and then conditionally get the specific machines printing form.

Choice fields can specify a "choicesFunc" method, which gets us some of the way there. However your advanced usage probably comes after this PR is merged in (as a starting point)

[wolflu05]

Use either a DRF serializer or Django model, and it will be taken care of for you. Check out metadata.py - this is where most of the magic happens. All of the current "front end" forms are constructed from that data.

I still think we need something generic with our own options. I don't think that DRF serializers have e.g. dependent options, sub forms, and also a lot of the stuff you Implement.

[matmair]

If it touches the python API I wold probaly move it to another PR as we probably need to bump the API version

[SchrodingersGat]

This issue (and linked PR) are only to re-implement functionality we already have in the "classic" UI

[wolflu05]

We could probably implement an icon picker like the emoji keyboard on phones / the glyphs keyboard from iOS and maybe I bit more dense.

[github-actions]

This issue seems stale. Please react to show this is still important.

[wolflu05]

not stale

[github-actions]

This issue seems stale. Please react to show this is still important.

[SchrodingersGat]

Not stale, long running issue in progress

[XanderLuciano]

Make "footer" (buttons etc) stick to the bottom of the modal (no scroll)

Big +1 on this, the ability to click "submit" without having to scroll to the bottom is a killer advantage of the old UI vs. the new UI currently

Also, I know the old UI also handles "enter" as a modal form submission. This behavior also should be kept / added to the new UI.

This is a task I'm interested in submitting a PR for.

EDIT: Related Issue: https://github.com/orgs/mantinedev/discussions/1141

[matmair]

@SchrodingersGat is this still open/relevant and are the action items on top all still valid?

[SchrodingersGat]

This is sufficiently advanced that we can close it out. Nice work everyone :)