Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Form handling #363

Open
pythoneer opened this issue Feb 13, 2022 · 1 comment
Open

Form handling #363

pythoneer opened this issue Feb 13, 2022 · 1 comment
Labels
C-enhancement Category: new feature or improvement to existing feature S-needs-design

Comments

@pythoneer
Copy link

pythoneer commented Feb 13, 2022

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)
  • Build-in-validators (Email, Phone number, is a number, is text, number greater than etc. . https://github.com/Keats/validator )
  • Initial-values (load a user entry and change things ..)
  • Field/Form-states (pristine, dirty, touched, untouched, valid, invalid, enabled, disabled ...)
  • 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.

@pythoneer pythoneer added the C-enhancement Category: new feature or improvement to existing feature label Feb 13, 2022
@lukechu10
Copy link
Member

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".

@lukechu10 lukechu10 changed the title Formhandling Form handling Feb 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: new feature or improvement to existing feature S-needs-design
Projects
None yet
Development

No branches or pull requests

2 participants