DDS to use deep-cloning / immutable objects when raising events, returning current state

[vladsud]

Let's consider a case of ISharedMap (as an example) and a value stored in it being an object (any mutable object, like an array, or object with properties).

There are 3 key workflows:

1. Setting new value for a key:

   const value = {a: 6, b: 7};
   map.set("mydata", value);
   value.a = 5;

2. reading data:

   const value = map.get("mydata");
   value.a = 4;

3. get, modify, and set data:

   value = map.get("mydata");
   value.a = 5;
   map.set("mydate", value);

Requirements:

1. After value is set on DDS, original object stays mutable. I.e. it's not deep-frozen. Making any changes on this object has no impact on a value stored in DDS.
2. It's impossible to change DDS value by mutating value retrieved from it (case # 2 above).
3. Convenience (optional, but highly desired): get-modify-set cycle should be easy to use, ideally without a need to deep-clone an object retrieved from DDS in order to mutate it.

Today, first two scenarios are broken.
While third one sort of works, but really broken as value change event is incorrect (it would say that nothing changed).

There are 3 possible mechanisms we could use here:

1. Deep freezing objects. This does not work well for set & get-modify-set scenarios.
2. Deep readonly types - this only works for get scenario. Does not help at all with set and makes user dep clone data for get-modify-set
3. Deep cloning on get & set. This works pretty well from usability and correctness points of view.

So it looks like deep clone is the only possible solution here.
Please note that from implementation perspective, it does not have to be full clone.
Libraries like Immer and immutable.js could be used to optimize process here.

As for API surface, that implies to everything, including change event notifications - we should never ever expose internal data structures for user to be able to directly modify them.

[microsoft-github-policy-service]

This PR has been automatically marked as stale because it has had no activity for 60 days. It will be closed if no further activity occurs within 8 days of this comment. Thank you for your contributions to Fluid Framework!

[microsoft-github-policy-service]

This issue has been automatically marked as stale because it has had no activity for 180 days. It will be closed if no further activity occurs within 8 days of this comment. Thank you for your contributions to Fluid Framework!