Override wrappers

[redhead]

I thought that sentence "Specifying this property will override the wrappers for the type for this field." in the description of wrapper property of fieldConfig will do as says when specifying this in my field:

wrapper: ['bootstrapHasError']

Meaning I want a field without bootstrapLabel, but I want to get error classes on the container. However, this wraps the default type wrappers into another bootstrapHasError, not overriding them but adding additional one.

If I specify null it overrides it in the way I get no wrappers at all. I just want to remove one of the default wrappers. Thus, the documentation isn't detailed enough.

How can I do that?

[kentcdodds]

Good question. I believe the docs are unclear. If the type you have specified has wrappers assigned to it, then the only way to get rid of them is to use null which will remove all wrappers (as you have pointed out). There is not currently a way in angular-formly to completely override wrappers. So you'll have to create another type that has the wrappers you want. You can use formlyConfig.getType to copy properties from an existing type to a new, similar type that you create.

I'm thinking that as a breaking change for the next version, I'll make it so that if wrapper are specified on the field, then the type's wrappers will not apply. That seems to me to make the most sense. (while I'm at it, I'll change the name from wrapper to wrappers because most of the time it is specified as an array anyway.

[kentcdodds]

Would love feedback from anyone on this breaking change for the next version:

1. Any problem changing the term wrapper to wrappers as it's specified as an array most of the time?
2. Any problem removing the default wrapper behavior? Basically, if you specify the name 'default' then it will wrap all types. This is a little bit too magical I think. And I believe it's undocumented.
3. Any problem changing behavior so that if you specify a wrappers array on a field then rather than joining with the wrappers from the type, it entirely overrides them?
4. I've recently thought that <formly-transclude></formly-transclude> is quite long. Any suggestions on whether it should be something else/shorter?
5. Anything else anyone would like to see change in wrappers?

[redhead]

No problem with any of those. Just 4) is only cosmetic and I think it's not really neccessary to rename that, formly- prefix is used in formly everywhere as convention and transclude is just what it is and everyone knows what it does.

[pdemilly]

Should wrappers be a map then and we could overwrite the key with a new value or a null to remove it. Then you could test if it's an array you keep the old behavior if it's a map you implement the new behavior. The keys of the map could be label and error for example

[kentcdodds]

Good comments @redhead. I'll keep the formly-transclude then

@pdemilly, I love the idea of it being an object with keys. The problem with that is how to define order. Once you do that you get into an issue with priority... We've talked about this on #368. What we could do though is give a wrapper an ID and you could optionally specify a wrapper as an object with a name and an id. Something like:

wrappers: ['foo', {name: 'bar', id: 'barWrapper'}]

Though I still think that this is less simple than just overriding the type's properties altogether. Thoughts?

[redhead]

What about just making it a function then, giving it wrapper array parameter and let the user do whatever he wants with the list - pushing new, remove unwanted, replace, reverse... 

[kentcdodds]

Oh, I like that a lot. And that could be non-breaking as well... Problem is that it's not quite as obvious, so I think I'll still have a breaking change to make it override wrappers when specified, but I think optionally giving it a function opens a lot of flexibility.

[redhead]

Agreed, it's not obvious, but good documentation is the core of every project anyway :)

[ckniffen]

Any problem removing the default wrapper behavior? Basically, if you specify the name 'default' then it will wrap all types. This is a little bit too magical I think. And I believe it's undocumented.

I would like that feature to stay. I find it very useful especially when every field defines its own special things it is an easy way to extend types defined in a third party templates library.

[Mig1st4ck]

I would like this feature implemented.

Override should be the most intended behavior.

Using an object instead of an array could be cool so we could set it like this:

wrappers: {
    'override': false, /* a special key could be used to allow not to override */
    'bootstrapLabel': 10, /* using an int would set the priority of each key map */
    'bootstrapError': false || 0,
    // 'bootstrapXPTO': 0 /* any non declared wrappers would be set to false, unless override was set to true */
    'dynamic': {
        priority: 15,
        template: '<div></div>' /* this could even allow a dynamic wrapper on the fly... */
    }
}

This would pretty much give all needed functionality on this subject.

[kentcdodds]

Definitely not going to get into priority. I would hate to see the day where I see: priority: Infinity and priority: Infinity + 1 :-(

We need this to be simpler, not more complex.