🙋 Feature Request
Add migration guidance for the deepMerge array replacement behavior introduced by #7559 in @microsoft/fast-html.
🤔 Expected Behavior
Consumers should be able to find a concise note explaining that observerMap-managed array properties are replaced during deepMerge instead of mutated in place. The guidance should recommend re-reading arrays from the owning object after deepMerge rather than relying on previously captured references.
The note should also clarify that f-repeat bindings observe the new array reference automatically when the owning property is notified.
😯 Current Behavior
The README and DESIGN docs mention that observerMap-managed arrays are replaced during deepMerge, and the change file uses a breaking: prefix. However, consumers reading release notes or migration guidance may not realize that code holding a stale reference to an observerMap-managed array now reads disconnected data.
Example:
const oldOrders = user.orders;
deepMerge(user, {
orders: [{ id: 103 }],
});
// oldOrders is now disconnected from user.orders.
The exported deepMerge helper also has a broader compatibility surface for direct consumers that relied on in-place array mutation.
💁 Possible Solution
Add a short migration subsection to the @microsoft/fast-html README, package docs, or changelog location used for breaking/prerelease notes. Include:
- array reference replacement on
deepMerge;
- recommendation to re-read
obj.arr after deepMerge instead of caching the reference;
- interaction with
f-repeat bindings, which observe the new reference automatically;
- scope of the change: observerMap-managed data and direct consumers of the exported
deepMerge helper that relied on in-place array mutation.
🔦 Context
PR #7559 intentionally changed observerMap deepMerge array behavior to avoid synchronous reentrant array notification work. This issue makes the migration impact explicit for consumers and future maintainers.
Searched existing issues for overlapping deepMerge array replacement migration docs and did not find a duplicate.
💻 Examples
Before relying on a cached reference:
const oldItems = data.items;
deepMerge(data, nextData);
oldItems.push(newItem); // mutates the old array, not data.items
Preferred pattern:
deepMerge(data, nextData);
data.items.push(newItem);
🙋 Feature Request
Add migration guidance for the
deepMergearray replacement behavior introduced by #7559 in@microsoft/fast-html.🤔 Expected Behavior
Consumers should be able to find a concise note explaining that observerMap-managed array properties are replaced during
deepMergeinstead of mutated in place. The guidance should recommend re-reading arrays from the owning object afterdeepMergerather than relying on previously captured references.The note should also clarify that
f-repeatbindings observe the new array reference automatically when the owning property is notified.😯 Current Behavior
The README and DESIGN docs mention that observerMap-managed arrays are replaced during
deepMerge, and the change file uses abreaking:prefix. However, consumers reading release notes or migration guidance may not realize that code holding a stale reference to an observerMap-managed array now reads disconnected data.Example:
The exported
deepMergehelper also has a broader compatibility surface for direct consumers that relied on in-place array mutation.💁 Possible Solution
Add a short migration subsection to the
@microsoft/fast-htmlREADME, package docs, or changelog location used for breaking/prerelease notes. Include:deepMerge;obj.arrafterdeepMergeinstead of caching the reference;f-repeatbindings, which observe the new reference automatically;deepMergehelper that relied on in-place array mutation.🔦 Context
PR #7559 intentionally changed observerMap
deepMergearray behavior to avoid synchronous reentrant array notification work. This issue makes the migration impact explicit for consumers and future maintainers.Searched existing issues for overlapping deepMerge array replacement migration docs and did not find a duplicate.
💻 Examples
Before relying on a cached reference:
Preferred pattern: