-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
RFC: Form Validation #407
Comments
Don't forget about i18n there. |
Could you expound a little? |
SUI form validation has default messages for shorthand rules. There is must be ability for redefine these messages 🔨 |
Gotcha, agreed. |
Hi, I am trying to write validation for form fields myself, and find this threads. It would be nice to have a simplified API outside Form as indicated on the top of this thread. But I think it would also be nice to provide some straight forward way/api to validate input fields manually. Maybe, like
The validate method is called when the form is submit. When failed, the error message may be passed to its own state? |
This was also my first inclination. Having the ability to validate a single field seems useful. I can see an equally valid argument that says, still validate the entire form model but only against a single field (e.g. do not specify validation for the other field names). What I'm less sure of is what the API looks like for wiring the model, field values, and error messages into the UI. @davezuko did you begin work on validation the other day? |
generally, serializer may pick up these information from states of sub-components? just my 2ct. |
Yep, generally it is clear. Specifics on the best way to do this is what I'm not clear about. Would love to see some experiments on this though. Goals being:
|
@levithomason - Not sure if this is beyond the scope of this issue, if so lmk and I can possibly open a new issue. I was having some discussion with my team about building a form component on top of stardust forms, but given some of the things mentioned here I'm wondering how much we're willing to build directly into stardust. We're planning to do the work anyway, so would be cool to spread the love 😄 Just going to copy/paste a comment I wrote in our project, would love your thoughts on this: Some thoughts:
onFormSubmit (values) {
model.updateValues(values)
}
renderForm () {
<Form formSchema={formSchema} defaultValues={model.values}, onSubmit={this.onFormSubmit} />
} Form Schema
Given a schema:
We should render: <Form>
<Form.Field control={Input} name='firstName' /* Other props */ />
<Form.Field control={Input} name='lastName' /* Other props */ />
<Form.Field control={Button}>Submit</Form.Field>
</Form> For inputs that should show up next to each other:
<Form>
<Form.Group widths='equal'>
<Form.Field control={Input} name='firstName' /* Other props */ />
<Form.Field control={Input} name='lastName' /* Other props */ />
</Form.Group>
<Form.Field control={Input} name='title' /* Other props */ />
<Form.Field control={Button}>Submit</Form.Field>
</Form> For inputs that are collections (e.g. email addresses) :
<Form>
<Form.Group widths='equal'>
<Form.Field control={Input} name='firstName' /* Other props */ />
<Form.Field control={Input} name='lastName' /* Other props */ />
</Form.Group>
<Form.Field control={Input} name='title' /* Other props */ />
<Form.Group widths='equal'>
{
emailAddresses.map((emailAddress, index) => (
<Form.Field control={Input} name=`emailAddresses.${index}.label` /* Other props */ />
<Form.Field control={Input} name=`emailAddresses.${index}.address` /* Other props */ />
)
}
<Form.Field control={Button}>Add Email Address</Form.Field>
</Form.Group>
<Form.Field control={Button}>Submit</Form.Field>
</Form> If you've gotten this far haha, regarding validations:
The nicest thing with this approach is that you're keeping everything in data and wouldn't need to touch the DOM. Using naming like |
I wound up implementing some of the ideas I wrote about in the previous comment. See the PR that's referenced right above ^ |
Awesome, working on an appropriate response as well. Will post shortly. |
This is definitely the right place, super thankful to see this. I agree with the goals here. I have mostly the same thoughts in terms of generating forms from an object, having a model, serializing on submit, validating that model, and showing errors. We also have a few form validation needs here at TA. Both in SPAs and static properties. Separation of ConcernsI'd like to create a set of packages that can work in any context, whether Node, SPA, or vanilla browser JS. I see a few separate pieces to this issue as a whole. We have already solved many of these problems at TA. We just need to pull them together, tweak some, and fill in missing parts. I'll layout what I see so far as the separate packages, then describe a potential workflow. FormThis is the Stardust Form and shorthand. Done
Needs
I'm curious if the shorthand and/or Form/Field data/error coupling should be a separate wrapper component as well, SerializerThis is currently baked into the Form component. Try it here. Done
Needs
SchemaWe may have create something here, but TA has also solved this on a broader scale with Obey. Might be a long shot, but I want to explore pulling what we can from there. Maybe breaking things out for reuse. Done
Needs
ValidatorAgain, Obey includes this. I'm thinking this should also be a separate package though. I just want a package that knows how to validate an object and returns the errors. Done
Needs
Theoretical Workflow
If these are separate packages, you can use schema/serializer/validator you want. We'll just ship with a sane default set. You can also use these packages in any other customized workflow you want. We could just bundle them in a sane default workflow. If we have a separate Finally, since these packages are not DOM dependent, nor React dependent, you can use them in Node or a vanilla DOM experience. It also means that we can look to the community for pieces of the tool chain. |
Is form validation currently possible? |
+1. Really could do with this. |
Formsy (/~https://github.com/christianalfoni/formsy-react) works really well for validation and form building in general. already has integrations for material UI (/~https://github.com/mbrookes/formsy-material-ui) and bootstrap. Would be cool to make a semantic-ui-react integration?? |
This is certainly something I'd like to explore. A simple wrapper around their API may be the best bet. |
I'm going to freeze this issue here. We've got some good notes and input above to work with. We've also got the advanced form work as a reference, #527. The immediate next step should be a PR exploring a thin wrapper around formsy-react. Future convo should happen on PRs related to this work. |
We're also considering options for implementing something similar to /~https://github.com/davezuko/react-reformed. |
I've pulled the 1.0 milestone from this issue. There are a lot of great ways to validate forms with extra packages. You can search our issues to find several. These should be used for now. We still plan on adding validation, it is just not a priority item for the core team ATM. |
There's also my package called uniforms. Currently it's not using this package but only SUI classes, but the concept is to abstract schemas into unified schema called bridge and provide many fields which are usable with any schema. (it's not an advertisement, but example of how to separate schema from components and DOM structure) |
I made a bunch of formsy-react wrappers for the form elements: |
Closing for housekeeping. We're still interested in elegant form validation within Semantic UI React and welcome PRs. Until then, there are plenty of workarounds above. |
I had the same struggle to do validation so i rolled out my own ADHOC validation, albeit, it can be better, one thing I struggled with, was that there is no clean API to update props outside of my render function, so each component needs a reference to the validator. The use of factories to create the components in SUI make them a bit of a locked box, if the form field could handle populating an error label it would great in addition to a label, here's some snippits:
To use, you i had to just import and muck with the Input, this only works with Input type fields. To use:
Hope this helps, validation is a pretty important feature for forms, and the biggest lacking feature IMHO. Any ideas how to improve this gladly accepted. Hope this helps |
This is a placeholder issue. Form validation will be implemented apart from the Form update PR #400. We've had a few offline discussions surrounding the validation API. Ideas will be posted here soon as we're able.
Have any input regarding form validation? We'd love to hear your ideas.
The text was updated successfully, but these errors were encountered: