Remove dataDeepCopy and propertyPassingDeepCopy in favor of non-copy-setData

[LastLeaf]

Currently these two component options are used to control whether the data should be copied while templating. It is component-level options, but it is more practical to control the deep copy strategies of each data field.

We want to remove them in faver of some advanced data update methods.

General API design:

• add an extra argument for replaceDataOnPath and spliceArrayDataOnPath for the DeepCopyStrategy ;
• add a new method updateAtomicData to set fields with DeepCopyStrategy.None .

[LastLeaf]

Need to resolve: how to specify atomic fields in initial data?

[LastLeaf]

We had a discussion today.

• dataDeepCopy and propertyPassingDeepCopy are simple ways to avoid copy. This should not be removed.
• They should still default to the current simple-deep-copy strategy to keep the compatibility with the legacy framework.
• For the partial-deep-copy strategy, we had following strategies to choose.
  1. Just leave it to component writers. It means dataDeepCopy and propertyPassingDeep should be no-copy whenever any field cannot be copied, and other fields should be immutable or manually copied.
  2. Allow any object-typed value to have a special JS symbol to specify how to copy it. This way allows the data provider to control how the data should be copied. It is very powerful, but the component writers can only treat the data as a blackbox and may miss-use it. Also, it requires an extra symbol check on deep-copy objects.
  3. Allow specifying a function which does the copy. It is highly customizable but it totally decoupled from the data provider, which means objects shared between multiple components require the custom copy function everywhere. However, this function can be specified through chaining filters so it may not be difficult to use.
  4. Allow each property specifiying its own property-passing-deep-copy strategy. This still requires the parent component specifying data-deep-copy strategy. This is easy to use and solves many problems, but limit to properties and also decoupled from the data provider.