Reducing usage of immutable

[elbakerino]

The initial reason why immutable is used in this lib, is to be able to reduce the rerendering even for dynamically changing non-scalar props.

I've realized this should be only necessary for the storeKeys, schemaKeys and dynamically changing schema (e.g. when using allOf/if/then/else etc.).

Thus it isn't necessary for the actual UIStore.values.

• dropping immutable for values and not for schema will be the easiest
• non-immutable values needs a change in all validators
• non-immutable values will need a new implementation for e.g. "have the values really changed" (user-implementation, change history)
• non-immutable values requires a new implementation of the storeUpdater logic parts
• non-immutable values requires a new implementation of the extractValue logic parts
• non-immutable values enables to correctly type them easily
• non-immutable values optimizes the combined usage with redux, as they are only using immer now instead of immutable

Because i'm using the is-the-value-the-same in a lot of places - and for e.g. Firestore integration it is currently essential for me - there will be most likely support for either native-values OR immutable-values, depending how the createStore is setup.

Easiest Option

This could be implemented rather easily after 0.5.0:

• keeping immutable:
  • schema/parentSchema
  • storeKeys/schemaKeys
  • errors (WidgetProps)
  • UIStore.validity/UIStore.internals
• immutable OR js-values:
  • UIStore.values / value
• problem: how should e.g. default be handled, as schema contains immutable but value may be expected to be js-value

[hennessyevan]

I would recommend waiting on Record + Tuple for this, it's a while away but I feel like this refactor is also a while away.

PROS: The accessor syntax is the exact same as object + array which would provide nice ergonomics while keeping the data immutable under the hood.

CONS: Proposal is still Stage 2 although it looks like it's progressing nicely tc39/proposal-record-tuple#336