Using form master with dockyard/ember-validations

[constantm]

Hi there!

I'm new to Ember and trying to get up and running with EFM2000 and ember-validations. I've gotten it to work up to a point, but I'm not sure where to go from here. At the moment, my validations work in the front end, which is great. The two problems I have are:

• The new template starts out with validation failed. How do I start with a non-validated object that updates per field as I go along?
• Thehas-error class never gets removed, even if validation passes. I had a look and the errors object it's looking at is empty. Why could it be that the class doesn't get removed?

My code is as follows:

//app/controllers/clients/new.js

import Ember from 'ember';
import EmberValidations from 'ember-validations';

export default Ember.Controller.extend(EmberValidations.Mixin, {
  validations: {
    clientName: {
      presence: true,
      length: { minimum: 5 }
    },
    clientEmail: {
      presence: true,
      length: { minimum: 5 }
    }
  },

  actions: {
    saveClient: function(){
      var newClient = this.store.createRecord('client', {
          clientName: this.get('clientName'),
          clientEmail: this.get('clientEmail')
      });
      newClient.save();
      this.setProperties({
          clientName: '',
          clientEmail: ''
      });
    }
  }
});

//app/templates/clients/new.hbs

{{#fm-form action='saveClient'}}
    {{fm-field type='text' value=clientName label='Client Name' errors=controller.errors.clientName}}
    {{fm-field type='text' value=clientEmail label='Client Email' errors=controller.errors.clientEmail}}
    {{fm-submit value='Save Client'}}
{{/fm-form}}

//app/templates/models/client.js

import DS from 'ember-data';

export default DS.Model.extend({
  clientName: DS.attr('string'),
    clientEmail: DS.attr('string')
});

As said, I'm super new to Ember so please tell me if I'm being stupid. :)

[Emerson]

Looking into this and will get back to you soon. Funny enough, I've never used ember-validation, but it's about time!

Hope to have some examples of this in action soon.

[Emerson]

After doing some research I'm sad to report that I don't think this is possible using ember-validations. It turns out that ember-validations has strong opinions about how it's meant to be used, which you can read about in detail here: https://github.com/dockyard/ember-validations/issues/152. The idea that records start off in an invalid state is by design and there are currently no plans to change that.

The author of ember-validations (Brian) has been pretty clear that: "ember-validations is only concerned with the model layer. I suggest that you look into how ember-easyForm is displaying errors".

So basically, if you want to use ember-validations, you need to use ember-easyForms or I need to rework EFM2000 to be more inline with ember-validation's philosophy.

In my opinion there are very legitimate use cases for:

1. Starting an entire record in an invalid state (ember-easyForm style)
2. Transitioning an entire record to an invalid state on demand (on submit, but before server side validations)
3. Transitioning individual fields to invalid states on demand (key-up validation or on blur)

Looks like it's time to write a validation library 👏 🎉 👏

I think I'm going to fork https://github.com/chriso/validator.js, convert it to an Ember-CLI addon, and write the code to handle these three use cases. I typically like validation libraries that provide validations (which is the hard part) and leave implementation up to the end user

[srsgores]

Ok, so I am just bringing this issue back up because I ran into the same problem.

Long story short: the validation methodology this library uses sucks. I think even @Emerson realizes this, as he suggested creating a validation library.

I am currently working on a re-work of validations, which use HTML5 validation: pattern, maxlength, required atrributes. It turns out that this library already implements some of these properties, as seen here.

Here is what I'm shooting for:

        {{#fm-form action="nextStep"}}
            {{fm-field type="text" label="First Name" value=applicant.firstName placeholder="First Name" required="required" autofocus="autofocus" title="What is your first name?"}}
            {{fm-field type="text" label="Last Name" value=applicant.lastName placeholder="Last Name" required="required" title="What is your last name?"}}
            {{fm-field type="email" label="Email" value=applicant.email required="required"  placeholder="Email" title="Please provide an e-mail"}}
            {{fm-field type="tel" label="Phone" value=applicant.phone required="required" placeholder="Phone" title="Please provide a valid phone number"}}
            <footer class="form-actions">
                {{#fm-submit title="Continue to Full Application"}}Continue Application{{/fm-submit}}
            </footer>
        {{/fm-form}}

Notice the autofocus and title attributes; when the required fails to validate, the error message displayed is the value of title. Note that this is the same functionality you get out of the box with HTML5.

For reference, I'm using ember-cli-html5 validations as a guide on this.

I will update as I get closer.

[Emerson]

Looking forward to hearing more @srsgores - I've been thinking things through and it's actually a really hard problem.

I can totally appreciate the logic behind ember-validations... which is basically "This library is used to determine validation states, not handle the display logic". On the other side of that, EFM2000 is kind of taking the same approach, which is "you figure out the validation states and just pass in the errors when you have them".

I've always used server side validations, which is why I never really considered this issue – but I fully agree with the sentiment that client side validations are an absolute must for any self-respecting form library and EFM2000 needs a way to accommodate this.

The big question I have right now is around API. What should it look like? I'm going to be putting more thought into this, but welcome any suggestions.

[constantm]

Okay so it seems I'm not completely stupid then. :) I'm just wondering what people generally use for validations with something like EFM2k. Like, you can't have form in an app without validations.

[Emerson]

I usually don't use live validations (on-keyup/blur)) and just let the server respond with the errors. Ember Data and EFM2000 should handle this pretty well out of the box, or you can explicitly attach the errors to your model object if you're not using Ember Data:

actions: {
  submit: function() {
    var user = this.get('currentModel');
    user.save().catch(function(xhr) {
        // Server returns something like: xhr.errors.firstName = ['required field', 'too short']
        user.set('errors', xhr.errors);
    });
  }
}

You can also see a manual version of this in the demo app here.

[constantm]

Aaah okay. That way is not ideal for a responsive user experience. I think in Ember it does actually make sense that a model object is invalid the moment it gets created. Perhaps an easier/more flexible solution would be for EFM2k to have options for when to display messages, along with some sort of good default. At the moment it shows all the time, but I think adding in an option to display the errors from the model per field on change/blur would go a long way. Then, if you don't want that per field functionality, errors could also be invoked for the whole form by toggleErrors. Would something like this be viable?

[emablekos]

Bump to this. I think it makes sense for the model to know its invalid, but the form view not to care until you have defocused.

Could get a little hairy on form reset, but seems like you just need a some internal state on each field to know if it has been defocused.

In the opensource spirit, it would be better to fit in with EmberValidations than add another validations lib to the mix.

For now i have a computed property proxying the errors property so i can toggle it:
formSubmittedOnce:false, formErrors:Ember.computed('formSubmittedOnce', function() { return this.formSubmittedOnce ? this.errors : {}; }),

[Emerson]

Cool, agreed that we need to tackle this. Trying to think through the API before writing the code. I'm thinking this could be something like:

{{fm-form delayErrors=true}}
{{/fm-form}}

Which would prevent the form from render the initial errors.

What about individual fields? Maybe you can define it on the entire form or alternatively, define it on individual fields as needed...

{{fm-field delayErrors=true}}

[srsgores]

Out of the box, validation should occur on the client-side. delayErrors is misleading to me in that errors won't necessarily have to be delayed. Perhaps validateOnServer would be a better bet.

In general, though, I think the best validation pattern is to have validation on the client and on the server; in most cases, I think it makes most sense to have basic validation on the client, with any validation required by the server as an additional layer. So for this add-on, it might make sense to get rid of an option altogether, in favour of an approach which lists any server-side errors alongside the client-side ones.

[Emerson]

Not sure I fully agree with this. Validating on the client is nice UX, but validating on the server is required and needs to be done regardless of how you build your application. I've always seen client side validations as an enhancement rather than a requirement.

This being said, I think there is room for both options. This could be something that could also be set in the initializer. If there really are more people who feel that client side validation should be the default, I'd be fine with turning this delayedErrors option on by default and allowing an override in the initializer.

Busy for the next couple days, but planning on working through this soon. It's possible we'll find a more elegant solution once we start writing the code.

Happy to hear all sides of it!

[ScottSmix]

Just thinking out loud here... Because there can be "n" number of validations per input field each with their own default message, it seems like the pattern below might be desirable. Any number of "fm-validator" can be nested inside a field. Each type of validator (except custom) would have a standard message which could be overridden.

{{#fm-form action='submit'}}

{{#fm-field type='text' value=model.first_name label='First Name'}}
{{fm-validator type="required" value=true}}
{{fm-validator type="custom" function="myCustomTest" message="You cannot be named John"}}
{{/fm-field}}

{{#fm-field type='password' value=model.password}}
{{fm-validator
type="regex"
value="^[a-zA-Z]\w{3,14}$"
message="Invalid password"
more="The password's first character must be a letter, it must contain at least 4 characters and no more than 15 characters and no characters other than letters, numbers and the underscore may be used"
}}
{{fm-validator type="exclude" value="A123" message="A123 is just too simple"}}
{{/fm-field}}

{{#fm-field type='text' value=model.age}}
{{fm-validator type="between" minValue=18 maxValue=65}}
{{/fm-field}}

{{fm-submit value='Create'}}
{{/fm-form}}

Validators could initially be simple like required, minLength, maxLength, minValue, maxValue, "regex", "between", "outside", "numberOnly", "custom" (function) and maybe a couple more. The idea would be to loop through the form field components and each validator sub-component, test and ultimately show error message if any don't pass.

[constantm]

I feel like these should be set in the controller, and ideally be supported by the validation library used. That is if FM2k doesn't get it own baked in validator.

[Emerson]

I have a branch that I've been working on that offers delayed errors - so that fields/forms (can optionally) only display errors after blur or on update. This would give us better compatibility with the easyForm validations.

@ScottSmix - that's a pretty interesting idea, something I would have never considered, but I'm seeing some value in it. Love how explicit it is and how easy it would be to add your own validation components. I'm going to mull it over for a little.

It's really hard. I like the idea of validating everything in controllers or components, but it requires a lot of boiler plate if you want to add that to every form.

Looking at liquid-fire as a reference, I'm starting to think of a pattern that might define a few out of the box validations, but also allow users to add validators to their app as small ES6 modules. These modules could be generic and used across multiple form fields, or more specific if you need something really custom. Using standard ES6 modules for validations will also allow the validators to be used in different contexts, not just as template helpers.

// A specific validator to ensure only people named Tom are valid
// your-app/validators/name-equals-tom-validation.js
export default function(value, errors, event, model) {
  /*
  * value: The value of the field
  * errors: The errors object, allowing you to change other validation fields
  * event: The event that triggered this validation cycle (submit, change, keyUp, blur)
  * model: The model object so you can compare other values
  */
  errors.name = [];
  if(value !== 'Tom') {
    errors.name = ['Your name must be Tom']
  }
  return errors;
}

Meanwhile in your template

{{!-- Referencing a custom validation using the validate-with attribute --}}
{{fm-field validate-with='name-equals-tom' model=model}}

I think that pattern for specific validations could work, but I'm struggling to think of an API that would allow users to easily define multiple validations on a single field. Two options for generic validations that I can think of:

{{!-- comma separated attribute --}}
{{fm-field validate='minLength=10,maxLength=20,email=true,required=true'}}

{{!-- sub expressions --}}
{{fm-field (validate minLength="25" maxLength="20" email="true" required="true") }}

Any thoughts on this stuff? I'm personally feeling pretty good about it.

[ScottSmix]

@Emerson, thank you for taking the time to mull this over. I like the idea of defining validators as components. I think the problem with a pattern that includes the validators inside the fm-field element is that customizing messages or adding additional properties to each validator type would be messy. I think having the nested components is clean and would allow anyone to develop validators without syntax limitations. New validators should extend a validator base class.

So, I'm still leaning toward something like:

  {{#fm-field type="text" label="Name" value=model.name}}
    {{fm-field-validator type="required" value=true}}
    {{fm-field-validator type="custom" value="name-equals-tom"}}
    {{my-own-validator anyProperty=x someOtherProperty=y}}
  {{/fm-field}}

In the ES6 example, I think it would be good to consider updating ember-data .errors if the model is an ember-data model. By considering this, we can have server side errors and client side errors unified. Developers could also push errors into the unified errors from controllers too. So, validators would just run and push into a errors. Controllers could push there too. FM2K could have a standard template to display all this on the form. This template could be modified by individual developers as needed.

I also think that whatever the solution is that we should keep in mind that there can be several errors for the form and several errors for each input within the form. So the stock template for fm-field should show the label, the input and "n" number of errors.