Recently I was try to convince a friend to use Ember in his next project, and he said he will consider and do some researching.
Yesterday he wrote me an email and told me he think Angular is better on form validations than other competitors, and he believes form validations is one of the most complex and frustrating job that every front-end developers has to deal with.
And finally, he choose Angular no matter what I say about the other advantages that Ember has. this is not a big deal actually, but the questions and needs about form validations is always place Ember in an unfavourable situation.
Now I have the same question as my friend, from its design principle, why Ember didn’t choose to implement a built-in form validation facilities in the first place? Look, I’m not saying Ember should or should not to do that, I just curious about the reason behind, and what’s the cons and pros with/without built-in form validation?
And if necessary, I think it is a good idea to explain this in Ember Guide, plus with the best practice suggestions on this topic will much better. This is indeed most developers care about.
Hm…not that familiar with how Angular does validation, but I do agree that forms are complex subjects that should not be taken lightly. I think Ember may have dodged the issue because there are no single solution that fits for everyone. So they pushed the responsibility to application developers.
Validation is indeed complex but it would not fit Ember to dodge the issue. Ember is very opinionated and goes to great lengths to come up with abstractions that fit most of the cases out-of-the-box and that gives the exceptional cases something to easily modify. It’s probably just a matter of time.
It’s pretty easy to handle your validations server-side, and then just return some error codes to say why. I actually think that if you must implement client-side validation for some reason, it’s not that hard to handle anyway. In the end, it’s a matter of display, and that’s app-specific.
And that would be the approach most libs, or even frameworks, take. As far as I understood, Ember wants to stand out by being opinionated and building higher, as Tom and Yehuda put this forth in their famous FluentConf presentation.
I think the argument that client-side validation is not hard to handle is not an argument for pushing this on app developers instead of building it into the framework. It is display-specific but one of the great things in Ember (and probably other frameworks, too) is that this does not prevent it being implemented in a generic way. Validation just sets the errors property of the underlying model while templates show these errors as they wish.
I think the problem of validation is not that simple, though, and might have to depend on a specific interface of the model library (like having an errors property on all model objects).
No, it’s not easy at all to do validation. For example, data in one field (or the validation status of it) could affect the validation of another. Say a country selection should affect the validation of other address fields. This alone can create a lot of bespoke code.
When doing the validation server-side it gets more complicated as you need to pass error messages back and forth. Which means you’ll also need a mapping so you know which error message belongs to which field. And it can get even more complicated since you’re not only dealing with validation errors but also server errors (“server error: could not look up post code” or “connection timeout”), or when I18N is involved.
I think it’s better to leave the choice of implementation to the user … though perhaps the documentation should provide guides / recommendations on good solutions or even best practices, if there is such a thing.
DS.Errors is really nice, but it’s not enough. Users shouldn’t have to fill out an entire form, submit it, wait for the response only to see that their password is too short. It should be shown as they type or on blur.
I also think that https://github.com/dockyard/ember-validations is your best bet. However for some reason, DockYards has still to convert it into a usable addon for ember-cli… They @bcardarella promised he would do it “very soon” when he did this presentation Ember-Validations & Ember-EasyForm - YouTube a while back, but looks like they/he have been too busy. Step up to the plate (someone?). Or maybe I will have to do it…??
In any case, I think that EmberJS should focus on the core infrastructure and form validation is not really “core” to my mind. Better to leaved it as an add-on option for people to submit different solutions. One size does not fit all, at least not yet
I’ve built a small lbirary for Ember-Data (it was for an older version of Ember-Data, I’ll soon update it for a newer version and make it an Ember-Cli addon). It uses HTML5 validation to provide direct validation and then fallback to extracting server side errors from DS.Errors.
It’s much simpler than ember-validations in the sense that it only allows to validate using built-in HTML5 validation (required, minlength, maxlength, pattern,…) and make things like validation depending on other fields value nearly impossible, but it does the trick and is super fast as it uses browser validation. Also, it needs a polyfill for IE9 and before.
In my opinion, validation should be done on the controller where the model is in the context of a view.
The same model may have different validation requirement under different context.
For example, a person may need to pay tuition fee when under the context of registering for course as a student. The person can also be an employee of the campus cafe where the person is owed wage. Suppose both of these two context are under the same system where the person have the role of both student and employee. If the validation is on the model, you need to validate for tuition fee when you’re in the context of employee.
Yup, @lightblade, that’s how you should do it. Forms are a display concern, they don’t even technically have validations if we are speaking about the business domain.
Stuff like alerts, notifications, error messages, etc are part of your UX, not a widespread convention everyone should adopt. I don’t even use forms in my apps.
It still needs tests, and I’m really not satisfied with the current server-side error handling, and lack some flexibility, but starts to looking code. Once again, the approach here is completely different than other form validation modules. This one goals is only to provide quick feedback using built-in HTML5 attributes only ;).
More of the same “one size can’t fit everything”.
ember-validate only validate whole object. Imagine multistage creator where following stages are only permitted if previous data is valid. Can’t do that with single form with fancy rendering.
ember-cli-html5-validation only use html5. And I know at least one nasty FF bug with input type=“number” validation.
DS.errors only handle back end. So not blazing fast validation on front end. (Though DS.errors should be part of any official validation solution if any will be adopted as such)
Anyone see validation lib for Ember that allow to group validation rules in sets and test given object against given group?
https://github.com/offirgolan/ember-cp-validations is a newer library that is quite extensible, supports i18n concerns, grouping validation rules, and is fully backed by computed properties instead of observers.
Let’s see some nice form and validation addons for ember-cli