You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is the idea on form handling in sycamore? Should there be, at least, a simple way of form handling build into sycamore or is this something that should be fully handled by an external crate?
In the case of "yes there should be, at least a simple way integrated" what should this look like and at which point should this be handed over to an external crate. Currently its a little bit tedious to make a form. And i think forms are quite important for SPA's (at least in the cases i create those, that might be different to others).
So what still counts under this "at least a simple way" under this umbrella? What i needed in the past was mostly:
Field-level-validation (must be a valid Email, must be lower than 100; between 200 and 400; bigger than 500 etc.)
Form/Group-level-validation (field a must be greater than field b, if checkbox c is checked field d must be not empty etc.)
Custom-validation (for all the crazy stuff and mostly Form/Group-level validation i think)
Error-messages (coming from the validators .. maybe as return values, easy access in view! for error messages)
Fields-as-groups (accessible by name e.g. username: Peter, password: goodpassword123)
Fields/groups-as-array (to add new entries like books, users)
Nested and Composable Group/Fields (a Userform can be composed from personal data, address, payment etc. group and validation can bubble up)
Dynamically created form (getting json – or whatever – from the backend and construct a form on the fly; so no hard coupling from Form <--> struct possible i guess)
These are just some of the things that come to my mind right now.
The text was updated successfully, but these errors were encountered:
Ergonomic form handling in Sycamore is pretty much non-existent right now. I believe the first step should be to improve the bind:x attribute for DOM nodes to make it easier to retrieve data from inputs. I think however that the form validation logic should be handled by a third party crate so as not to bloat up the main sycamore crate, allow more flexibility, and also allow different approaches instead of a single "official approach".
What is the idea on form handling in sycamore? Should there be, at least, a simple way of form handling build into sycamore or is this something that should be fully handled by an external crate?
In the case of "yes there should be, at least a simple way integrated" what should this look like and at which point should this be handed over to an external crate. Currently its a little bit tedious to make a form. And i think forms are quite important for SPA's (at least in the cases i create those, that might be different to others).
So what still counts under this "at least a simple way" under this umbrella? What i needed in the past was mostly:
view!
for error messages)username: Peter
,password: goodpassword123
)on the fly
; so no hard coupling from Form <--> struct possible i guess)These are just some of the things that come to my mind right now.
The text was updated successfully, but these errors were encountered: