1.0rc1 - Config validation failure when reusing views configs

[kfeinUI]

Ran into an interesting gotcha regarding the 1.0rc1 state configuration validation as I've been working on migrating from 0.x.

So I've got 2 states each having multiple views defined. For those views, they have the same config so I stored the object into a variable and plugged it into both. It's a simple config with a component and bindings. What I found is that a validation error would be raised on the second usage due to the presence of resolveAs on a component configuration. I tracked the issue down to ng1ViewsBuilder.js which modifies the input by applying a default value for resolveAs following the validation, thus making further usages invalid.

Obviously not a showstopper since the workaround is to simply apply a copy, but it was unexpected and may be worth looking at.

Otherwise the migration has been mostly smooth sailing! 1.0 addresses many of pain points of 0.x.

[christopherthielen]

Otherwise the migration has been mostly smooth sailing! 1.0 addresses many of pain points of 0.x.

Lovely, that's great to hear!

I think in general it's a good idea not to share object references in state definitions. We use object equality checks in various places in the code, so sharing references can be dangerous.

I thought through a few options such as making resolveAs a valid option for component views, but I think it's better to reject resolveAs on a component view during validation because it's most likely a developer mistake. I appreciate the bug report, but I think we will close as WONTFIX.

[christopherthielen]

I changed my mind. This is pretty easy to fix by making a shallow copy of the view declaration before processing it, and it seems pretty low risk.