Support attributes that contain collections of items - Feedback requested about angular-form-for

[zapnap]

Both proposals seem reasonable to me. I have a slight preference for the latter, as it's just a little bit DRYer (even if the brackets are just a bit aesthetically ugly). I never really cared for ngForm's approach of using extra ng-form elements to indicate the nesting level.

[bvaughn]

Thanks for weighing in. I also currently prefer the 2nd approach.

I spent a couple of hours working toward it on Friday but got side tracked this weekend overhauling the documentation UI. I'll probably play with this again some more today.

[zapnap]

Awesome, looking forward to it!

[bvaughn]

FYI I made some more progress on this today (in branch feature/19). I spent a fair bit of time implementing a work around for an Angular $parse bug so the branch didn't get done.

I'll pick it back up in the morning. :)

[zapnap]

This is looking great! Lmk if you need help / testers / etc. Can't wait to use it 😄

[bvaughn]

Thanks @zapnap! :)

I'm not at my dev computer right now and so I can't push a copy of my gh-pages branch, but when I get back to the computer maybe I'll shoot you a link. It's my integrated test harness now (ex. http://bvaughn.github.io/angular-form-for/#/demo/advanced-form)

[bvaughn]

Good news update :) I've got the handling of collections working in my local test harness. I need to spend a little time writing unit tests for the validations, but unless something goes wrong- I hope to make a 1.2 release sometime this afternoon. :)

[zapnap]

Killer!

pls excus typos. im mobile.
On Aug 19, 2014 11:51 AM, "Brian Vaughn" [email protected] wrote:

Good news update :) I've got the handling of collections working in my
local test harness. I need to spend a little time writing unit tests for
the validations, but unless something goes wrong- I hope to make a 1.2
release sometime this afternoon. :)

—
Reply to this email directly or view it on GitHub
#19 (comment)
.

[bvaughn]

I've got collections working, with an exception: removing any item in the collection except for the last one causes undesirable behavior. This is because ngRepeat's $index is changing, which is causing the input field's attribute to change - something previous unexpected.

I need to spend a little more time ironing this out (aka unregistering and re-registering fields in the event that their attribute changes). Pretty sure the fix is adding the following logic to each of the inputs (or a helper shared between them):

$scope.$watch('attribute', function(newValue, oldValue) {
  if ($scope.model) {
    formForController.unregisterFormField(oldValue);
  }

  $scope.model = formForController.registerFormField($scope.attribute);
  $scope.label = FieldHelper.getLabel($attributes, $scope.attribute);
});

I need to test it a little bit more to be convinced of the fix though.

[zapnap]

This would be undesirable for a large number of inputs but I can't think of a better way to do it personally. Also, it's probably an edge case anyway. Looking good!

[bvaughn]

Agreed, it would be less than ideal for a lot of inputs.

Of course you could always use another way of iterating over your inputs and assigning them unique indices. ngRepeat shuffles around and changes the $index but another solution could just go with a sparse array and avoid that.

[bvaughn]

Happy to say that this feature is now available via the new 1.2.0 release. :)

Here's a demo:
http://bvaughn.github.io/angular-form-for/#/demo/collections

And here's some documentation:
http://bvaughn.github.io/angular-form-for/#/validation-types

Give it a spin and let me know what you think!

[zapnap]

Great! I'll check this out later today or tomorrow and get it working in my project. Thanks!

[zapnap]

Thanks again for adding this Brian, it's shaping up nicely.

I'm likely just doing something wrong, but I'm having a hard time getting validations to work on the nested forms. Here's what I have for my service:

.service 'EpisodeForm', ->
  @validationRules =
    subject:
      required: true
    introduction:
      required: false
    link_references:
      collection:
        fields:
          name:
            required: true

These are bound to a form that looks similar to the below:

<form form-for="model" service="EpisodeForm" submit-with="save(data)" submit-error="saveFailed(error)">
  <text-field attribute="link_references[{{$index}}].name" placeholder="Placehjolder">
  <button type="submit" submit-button>submit</button>
</form>  <!-- can I get the submit-button bindings without the template? -->

Omitted the entire thing for brevity. But basically my saveFailed() method gets called, but then the save() method triggers anyway, and no fields appear to highlight the validation errors. I'll take another pass at this shortly, and will put together a fiddle or something if I continue having issues. In the meantime, if anything looks obviously broken to you, please do let me know!

[zapnap]

Quick update: I moved away from using a service to adding validationRules directly to my controller $scope, and now everything seems to be working, except for the fact that submitFailed() is no longer firing (??). However, the validation does now prevent submission and the fields highlight as expected.

[bvaughn]

Interesting. So you're seeing different results using the validation-rules setter and using a service containing rules? That's not intentional!

File a bug for me here and link it to a Plunker and I'll take a look.

[zapnap]

Yeah I should note that with the $scope.validationRules version, my submit-with callback isn't working either :). I need to break right now but I'll take another look shortly. Probably user error.

[bvaughn]

Roger that.

If you can't figure it out - or you suspect it's a bug (or bugs) in formFor - just file a bug report with a Plunker and I'll help you out. :)

[zapnap]

It's a little hard for me to plunkr since the API I'm hitting for ngResource or $http isn't public, but here's a stripped-down example that should at least demonstrate the problem:

https://gist.github.com/zapnap/db217d6595e1c45b266c

The validateAll promise never seems to get resolved in the formFor controller link function, though I'm not yet sure why. As mentioned, if you dummy up the data instead of using an $http or ngResource backend, everything works fine. I'll probably take another look if I can free up some time tomorrow afternoon.

[zapnap]

Looks like this was a data issue... but the behavior exhibited was pretty strange. I had a blank value for a required attribute coming down from the server (so the server-side data was itself invalid) and instead of triggering visible validation warnings, the callbacks simply weren't firing. I'll try to come up with a reproducible test case.

[bvaughn]

Ah! Sounds tricky.

I'm sorry that I haven't been able to help out so far, but if you can trap it in a Plunker (or even shoot me an email with HML+JS and an endpoint to test out) I'll look into it.

[zapnap]

I think this was just my misunderstanding that the submit-error callback should fire on validation failure. So this will only fire if the form is valid and the submit-with / submit handler returns an error? Or do I have that wrong? I basically want to be able to trigger an alert (flash) on validation failure.

[bvaughn]

Ooh! Moment of realization here. :)

Yeah, the error callback was only intended for failed form submits. Maybe you want to do something special (like show a "did you forget your password?" message).

I think it totally makes sense to have a separate event for failed submit-validation. Want me to add that? Toss it up as a feature request and I'll try to knock it out soon. :)

[zapnap]

Yeah that makes a lot more sense now :). Just got our wires crossed, no worries. And yeah, that'd be great. I'll open a feature request.