enhancement
major
minor
major
minor
Suppose a tl:TreeComponent is configured so that its root node is not displayed.
If the root node receives an update—for example, by changing the structure through reordering the children—a tl:SubtreeUpdate is created with a range of Control IDs, which is later used by the tl:TreeRenderer to update the (DOM) nodes in this range using a tl:RangeReplacement.
To determine the range of Control IDs in the SubtreeUpdate that are to be updated, the children of the root node that were not newly added by the update are required. The Control ID of the first visible node among these children is the left boundary, and the Control ID of the last visible node is the right boundary of the range to be determined.
The state of the tree on the server is taken into account, not the one on the client. This means that the “first” and “last” visible nodes may differ across the various updates triggered by user actions.
For example, if the children are reordered in a first update, the subsequent update refers to the state after this reordering. In particular, the first node to be updated is the one that is at the beginning after this reordering. As a result, the range of Control IDs to be updated in the second update may be “significantly smaller” than that in the first update.
This is a problem because, when there are multiple subtree updates to the root node, only the last update is taken into account and sent to the client. The remaining updates are discarded.
Example
Suppose a root node has three children : `A` (ID: 1), `B ` (ID: 2), and `C` (ID: 3). Using drag-and-drop , `A ` can be moved behind `C`. This is a user action, but in effect, two updates occur. The server only knows the state before and after the operation. The desired order is `B, C, A`, and the server now attempts to achieve this. Due to the lack of a “smart heuristic” to minimize the number of operations required, two operations are needed. The elements are now “moved” to their correct positions in the desired order.
First , `B` is “moved” to the correct position — that is , `A ` and `B` are swapped—and then `C` is moved to the correct position, meaning `A` and `C` are swapped. In total, two swaps or “moves” take place.
For the first update—that is, the first swap—the range 1–3 of IDs that need to be updated on the client is obtained. This is fine, since the state of the root node’s children on the server matches that of the client (`A`, `B`, `C`).
For the second update, however—that is, the second swap—the range 2–3 of IDs that need to be updated on the client is obtained. This is because, after the first swap, the underlying children of the root node on the server are `B`, `A`, and `C`.
Since only the latest update is now transmitted to the client, the user encounters a problem: a subtree that is “too small” is being updated.
Test
Start PDX and create three new top-level library elements under Products > Bill of Materials. Then drag the first child of the root node behind the last child and drop it. As in the example described, only 3 children of the root node should continue to be displayed.