Formatters and parsers consequences

[redhead]

I don't really like the current implementation of parsers and formatters, as for example these lines

https://github.com/formly-js/angular-formly/blob/master/src/directives/formly-field.js#L373-L378

can have unpredictable consequences (as it already had with making form dirty before the fix or rather "workaround").

I am facing a problem when using UI Bootstrap typeahead component. When I already have a model value set, and it is an object, I need to use a formatter so it displays some property of the model object when the field is rendered for the first time.

But if I use a formatter from formly, it triggers setViewValue which consequently triggers parser as well. For typeahead, setting a viewValue means the user has written something to the field resulting in calling the typeahead async options retrieval request to the server and displaying the results on screen.

The following happens when I just render a form on screen for the first time while having a model value already set:

1. formatters are set and called to format a model
2. setViewValue is called
3. parsers are called
4. typeahead's parser that queries the options is called
5. typeahead options get visible on page

First question, I don't really know how to handle this situation. I need a formatter because the model value is an object which I cannot "render" in the text field, unless formatted to a string (e.g. using some object property). But this implementation triggers the options retrieval and making them visible.

Second question, do you think this could be somehow rethought, for example adding a wrapping ngModel directive which would call some function on field options to get formatters/parsers and set them in the ngModel link function instead of much much later where we are forced to use setViewValue and setPristine and other workarounds so the formatters work?

[redhead]

So I figured out the problem using the input formatter which is provided by the typeahead component itself.

Leaving open for the second suggestion / question.

[kentcdodds]

I'm not sure I understand the problems with the current implementation. What do you mean by:

instead of much much later where we are forced to use setViewValue and setPristine and other workarounds so the formatters work?

I'm not sure what you mean...

[redhead]

The whole point of the lines I linked is because formly formatters are not called when ngModel is initialized, that's why they are being called manually when formatters are set by formly. I was just thinking the other way - have an ngModel (wrapping) directive that sets those formatters on ngModel controller in the link function, instead of doing it manually in formly field and having calls to setViewValue and setPristine, which can produce unexpected behaviour (just as in case of typeahead, although there it was not a problem in the end since it defines its own formatter attribute).

[kentcdodds]

Oh, I think I see what you're saying. So by adding the parsers and formatters after the ng-model has been initialized, they don't run and we have to manually run them. So what you're suggesting is we have another directive and add them to the ngModelController as you would normally. We do this same thing with validators with the formly-custom-validation directive. We could do something similar with a formly-parsers-and-formatters directive... I think that would make the most sense and clean up some code too...

[redhead]

Exactly! :-) Sorry for the confusing description, I was really tired :-D

[marcelinojorgeromero]

Hi there i was reading your posts because are related to my problem. I think formatters are not called correctly and as redhead points out they called manually, as what i suspected. Please take a look at my stackoverflow post where i have a demo example.

[kentcdodds]

Yes, this is a bug. Feel free to makeapullrequest.com

[marcelinojorgeromero]

Kent thanks for your reply, i would love to contribute to the project but i have hard time understanding the bigger picture and generally how angular-formly is made. Is there a possibility to create some instructions or diagrams or even a video (whatever) explaining how stuff glue together? I mean only the big picture of the source code... Thanks