On form submit, if validation fails, trigger an optional callback about angular-form-for HOT 9 CLOSED

Maybe an easy way to do this is to expose the errorMap object on the form controller. So you can do:

So in the view you can do:

<form form-for controller="formController">

And in the controller:

$scope.$watch('formController.errorMap', function(errorMap) {
  if (!_.isEmpty(errorMap)) {
    // custom warning
  }
}, true);

@bvaughn Thoughts?

from angular-form-for.

Nice suggestion.

@cissyshi I could expose the error map, but I wouldn't advice binding to it in that way because deep binding is unnecessarily expensive. It would probably be more performant to allow you to tap into the event with an optional handle (and then I could pass the handler the field-to-error map).

from angular-form-for.

This feature is now available in release 1.2.5

There's also an example of using the new callback on the docs site:
http://bvaughn.github.io/angular-form-for/#/demo/simple-form

from angular-form-for.

Looks good. Any plans to provide a way to get a reference to the field(s) that failed validation?

from angular-form-for.

Hmm providing access to validation field references might also be a way for users to implement something like what was mentioned in #25

from angular-form-for.

I don't know. I thought about this but I shied away from it for a couple of reasons:

• The format of the error messages is one that makes sense to formFor but might not make sense to an external consume without some cleanup. (For instance, errors are currently being stored in 2 separate objects- one for collections and one for fields, more on why this is below.)
• (Your) controller logic has access to the full form-data object and so technically has the ability to determine which field(s) are invalid (although I realize this is a bit redundant with one of formFor's main jobs).

So why are the validation errors stored in 2 objects? To prevent naming conflicts. For instance, consider the collections demo form which defines data in the following format:

{
  name: '',
  hobbies: [
    {
      name: '',
      frequency: '',
      // etc.
    },
    // etc.
  ]
}

This form specifies validation constraints on both the collection of hobbies and the individual hobbies such that validation errors could look like this for the collection:

{
   hobbies: 'Must specify at least 2 hobbies'
}

Or this for items within the collection:

{
  hobbies: {
    name: 'Field is required'
  }
}

In order to avoid conflicts I store those errors in separate objects/maps. It's not immediately clear to me how I'd merge them into a single, meaningful or intuitive data structure for use outside of formFor.

Thoughts?

from angular-form-for.

That's fair, and the internal representation makes sense. Not really sure what the best way to handle it would be, especially for the 'collection-level' issues like min and max items, which aren't really specific to a field per se (but then again, you wouldn't highlight those errors or scroll to them anyway because there's no explicit field to indicate).

The actual field-level errors could be simpler to address and are probably more commonly needed. Something like emitting a standardized validationError object when validation on them fails and then the top-level handler could be invoked with that object. But yeah, not a complete solution really.

from angular-form-for.

I'd be tempted to just expose the field-level errors- but I think that might lead to confusion in the case of valid fields and invalid collections, because the validation failure handle would be invoked with an empty object. I could see that being very counter-intuitive.

from angular-form-for.

Yeah I can see that both ways. On one hand, they'd be handy to have. On the other, yup, potentially confusing when empty. What if the collection-level validations returned some sort of "base" key to gather all the collection-level items under.

For example, something like:

{
  hobbies: {
    base: 'Must specify at least 2 hobbies'
    name: 'Field is required'
  }
}

Just a thought.

from angular-form-for.