Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

$parsers functions may not run when they should #8077

Closed
Alexsey opened this issue Jul 4, 2014 · 9 comments
Closed

$parsers functions may not run when they should #8077

Alexsey opened this issue Jul 4, 2014 · 9 comments

Comments

@Alexsey
Copy link
Contributor

Alexsey commented Jul 4, 2014

Here is plunker

  1. Enter 'aaa' in input
  2. Remove focus outside of input
  3. Clear input and write 'aaa' again

Result: 'aaa' in input, 'a.a.a' in model
Should be: 'a.a.a' in input and model should not be different from input

As we can see in console, $parsers functions are not running after changing input value to one was entered before, even if it where changed between inputs

@Alexsey Alexsey changed the title $parsers function are not running for second same change if model is updating on-blur $parsers functions are not running for second same change if model is updating on-blur Jul 4, 2014
@Alexsey Alexsey changed the title $parsers functions are not running for second same change if model is updating on-blur $parsers functions may not run when they should Jul 4, 2014
@Narretz Narretz added this to the 1.3.0 milestone Jul 4, 2014
@Alexsey
Copy link
Contributor Author

Alexsey commented Jul 4, 2014

And if the idea was not to trigger $parsers chain if value remains the same, then this is also broken, because if we

  1. Enter 'aaa' in input
  2. Remove focus outside of input
  3. Clear input and write 'aaa' again
  4. Focus input
  5. Remove focus outside of input

Result: 'a...a...a'
Should be: 'a.a.a'

If it was the idea, of cause

@petebacondarwin
Copy link
Contributor

@Alexsey - this is not really what $parsers are supposed to be used for. The $parsers are to transform the view value into the model value only. You should not be using them to try and change the value of the actual input code.

Moreover $parsers and $formatters should be reciprocal so that you can change the model or the view and the whole system will stay in sync.

You can see this working here: http://plnkr.co/edit/vq5c1CgkxmVdynWjj8WG?p=preview

What I suspect you really want to do is actually write specific handler code inside your own input directive that handles the blur event and updates the viewValue before it is passed to ngModel at all.
Perhaps something like this: http://plnkr.co/edit/wdIP5xZzpKy3da7cKWxJ?p=preview

@shahata
Copy link
Contributor

shahata commented Jul 8, 2014

@petebacondarwin I think we should document that ngModelController properties like $viewValue and $modelValue (actually, I think almost all of them except for $parsers, $formatters, etc.) should be read only and should only be changed by ngModelController itself (maybe they should have been getters so that ppl won't be tempted to fiddle with them). Do you see any legitimate use case in which some directive touch those properties directly?

@Alexsey
Copy link
Contributor Author

Alexsey commented Jul 9, 2014

@petebacondarwin thanks, in case I need both: $parser and on-blur. For simplicity I just remove part that works right. But your example really help to understand how I should act.

@shahata about documentation: in $formatters description says that "Array of functions to execute, as a pipeline, whenever the model value changes" which is not true, because when model assign to and is changing by user $formatters functions are not running. But they do if model changes externally. It would be really nice to have explanation of when that run and when they not in the docs.

@petebacondarwin
Copy link
Contributor

@Alexsey - I agree, we could be more accurate on when $parsers, $formatters and $validators run - it is not simply when the model value changes, for instance, as you point out.

@shahata - I can't think of any valid case for modifying these directly.

@Alexsey
Copy link
Contributor Author

Alexsey commented Jul 9, 2014

@shahata + example in plunker of not calling $formatters on model change through input

@shahata
Copy link
Contributor

shahata commented Jul 10, 2014

@Alexsey - formatters run when the model changes programmatically. parsers run when the view value is updated (most commonly due to user input)

@Alexsey
Copy link
Contributor Author

Alexsey commented Jul 11, 2014

so, should issue be open till appropriate changes would be made in docs and/or readability of $modelValue, or separate issues should be created for those and this one closed?

@petebacondarwin
Copy link
Contributor

@Alexsey - could you please close this one and open a new issue about the docs?
Thanks

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants