Add parsers and formatters

[kentcdodds]

Feedback appreciated: It would be really handy to be able to specify parsers and formatters (to support use cases like this. Something like this:

vm.fields = [
  {
    type: 'input',
    parsers: [appendCurly],
    formatters: [hissToSnake]
  }
];

function appendCurly(value) {
  return value + '}';
}

function hissToSnake(value) {
  return value === 'hiss' ? 'snake!' : value;
}

Some cases to consider:

1. When merging the fields with defaultOptions we need to decide what order to apply the parsers and formatters (considering the order they are run in...)
2. Should we provide a mechanism to override parsers or formatters? We could allow you to specify a property on the function that identified the parser/validator (like id) and that would be used to override them.
3. Anything else I'm missing?

[ckniffen]

Is this for shiming the features of angular-1.3 with formly?

[kentcdodds]

@ckniffen, not sure I understand what you mean. The $parsers and $formatters apis are available in angular 1.2

[ckniffen]

Sorry I was thinking of $validators. That aside would this leverage $parsers and $formatters?

[kentcdodds]

Yes, it would be similar to formly-custom-validation except it would do something like: ctrl.$parsers = ctrl.$parsers.concat(options.parsers) or ctrl.$parsers = options.parsers.concat(ctrl.$parsers) depending on which order we decide to apply the new parsers.

Then there's the decision on how to merge them...

[benoror]

Shouldn't it just rely on NgModelController's $parsers & $formatters existing functionality?

https://docs.angularjs.org/api/ng/type/ngModel.NgModelController#$parsers

[kentcdodds]

@benoror, yes, it will, that's what I'm planning on doing. But we need to consider defaultOptions and overriding as well as considering existing $parsers and $formatters.

[kentcdodds]

That's mostly what I want feedback on (noted in the numbered list above)

[benoror]

My toughts:

1. Since "The functions are called in reverse array order" I think the ones in defaultOptions should have more precedence, therefore should be pushed last
2. Since pushing a function with the same name won't override it, I see 2 possible opts:
   1. A simple mechanism to override defaultOptions when specifying the same name (acting more like an object)
   2. Use of ID's to specify overriding

[kentcdodds]

Sounds good.

For your "as an object" suggestion, I considered that as well. The problem is then you have to figure out how to determine which to push on the pipeline first. So I think that an id would probably be better. But can anyone think of a use case where this would be needed? I think I'll leave it out until someone mentions they need it...

[zeddever]

+1 for this, I was about to open a PR for comments when I saw this one.

WRT a use case, I currently have dates that I push from the server in ISO8601 but allow the users to edit it in a more user friendly format. Ergo I'd need the parser/formatter framework to keep my model consistent. Of course I could go implement a directive but it felt like a better fit for this framework. Model transformation is a pretty common operation hence the support for a MV transformation framework being built as a part of angular core. Formly is essentially presenting a new interface (the old one being declarative HTML through the use of directives) to the form control features that angular supports but Formly doesn't give any interface to the formatters/parsers abstraction, which makes it an incomplete interface.

FYI, atm I have an extra 'Editor' abstraction between my actual model and my formly model and this abstraction allows me to do transformations outside of the parser/formatter framework.

Please implement this, as I think it would bring your framework full circle wrt interfacing to angular form functionality.

WRT the points you raised:

1. I also think defaults should take higher precedence, i.e. they should go to the end
2. I don't think you need to be able override parsers/formatters. It's a chain, and with defaults taking precedence, you can "override" by adding a formatter/parser later in the chain that transforms what the default chain segment gives you. If using a particular form custom type, there are certain characteristics that you should expect based on the contract provided by that form type, and it's these abstractions that you should be working with in your code.
   E.G. if your working with a "date input" type it might include default parsers and formatters to keep the model consistently a date object and the view consistently a string formatted as a 'fullDatetime'. If you wanted to customize that field type, eg, to change the format of the text rendered to the view, then you look at the interface documentation for the field and you know the new primitives to work with. I.E. to change the format, you need to either do the string munging manually, or better yet parse the new formatter primitive which is a 'fullDatetime' formatted string, then reformat the parsed string to your hearts content. On the other side, if you wanted to change the parsers chain, eg, maybe to add an offset to the date, the new primitive would be the date object that the contract that the "date input" field guarantees. If you need something outside of what the contract for the field guarantees, then you should make a new type all together or create a new abstraction where it makes sense. The field type should be immutable wrt it's contracts for the data interfaces.

Another potentially hairier issue is that if you try to override a part of an existing default chain segment then parts of that default chain segment might break since you might change the interface that a sub segment of that default chain segment expects.

Thanks for the great work on this library so far, and I hope you'll roll out this feature

[kentcdodds]

Here's my plan for implementation:

When merging parsers, they will be concatenated together. Options can be merged in four scenarios. This is the order the parsers will be concatenated (meaning the parsers will run from the top of this list to the bottom):

1. Extended type
2. Type
3. optionsTypes (in order specified)
4. parsers specified on the field

For example:

formlyConfig.setType({
  name: 'parent1',
  defaultOptions: {
    parsers: [parent1Parser1, parent1Parser2]
  }
});

formlyConfig.setType({
  name: 'parent2',
  defaultOptions: {
    parsers: [parent2Parser1, parent2Parser2]
  }
});

formlyConfig.setType({
  name: 'child',
  extends: 'parent1', // <-- note this!
  defaultOptions: {
    parsers: [childParser1, childParser2]
  }
});

formlyConfig.setType({
  name: 'optionType1',
  extends: 'parent2', // <-- note this!
  defaultOptions: {
    parsers: [optionType1Parser1, optionType1Parser2]
  }
});

formlyConfig.setType({
  name: 'optionType2',
  defaultOptions: {
    parsers: [optionType2Parser1, optionType2Parser2]
  }
});

// parser definitions excluded for brevity...

// elsewhere... in some controller
var vm = this;

vm.fields = [
  {
    type: 'child',
    optionsTypes: ['optionType1', 'optionType2'],
    parsers: [fieldParser1, fieldParser2]
  }
];

The resulting merged array for this field's parser would appear as:

[
  parent1Parser1, parent1Parser2,
  childParser1, childParser2,
  parent2Parser1, parent2Parser2,
  optionType1Parser1, optionType1Parser2,
  optionType2Parser1, optionType2Parser2,
  fieldParser1, fieldParser2
]

Formatters will be the exact same.

Could someone sanity check me on this one? It's a little confusing, I don't use parsers/formatters very often, so someone with more experience may be able to help me to determine the most logical solution. I think this is correct though. Just want to make sure that I'm covering my bases!

P.S. Doing something like this with that many parsers would be utter insanity... Just had that thought :-) But this is a very contrived example