Frontmatter
| id | 9435 |
| title | TreeStore: Fix visible projection for dynamic child additions to expanded parents |
| state | Closed |
| labels | bugai |
| assignees | tobiu |
| createdAt | Mar 10, 2026, 10:17 PM |
| updatedAt | Mar 10, 2026, 11:14 PM |
| githubUrl | https://github.com/neomjs/neo/issues/9435 |
| author | tobiu |
| commentsCount | 1 |
| parentIssue | 9404 |
| subIssues | [] |
| subIssuesCompleted | 0 |
| subIssuesTotal | 0 |
| blockedBy | [] |
| blocking | [] |
| closedAt | Mar 10, 2026, 11:14 PM |
TreeStore: Fix visible projection for dynamic child additions to expanded parents
tobiu assigned to @tobiu on Mar 10, 2026, 10:17 PM
tobiu added parent issue #9404 on Mar 10, 2026, 10:17 PM

tobiu
Mar 10, 2026, 11:13 PM
Input from Gemini 3.1 Pro:
✦ The code has been successfully committed and pushed!
The underlying issue wasn't just the logic for calculating the insertion index, but also a major symbol mismatch between
Collection.BaseandTreeStorethat causedTreeStore.splice()to fail to detect when filters were active.Summary of Fixes:
- Unfiltered/Unsorted Additions: Implemented
getInsertIndexForNodeto accurately calculate the flat projection index based on the preceding sibling's deep visible descendants, ensuring nodes are inserted perfectly after their parent in the_itemsarray.- Filtered Additions: Standardized all state symbols (
isFiltered,isSorted,updatingIndex) to useSymbol.for()globally acrossCollection.BaseandTreeStore.mjs.TreeStore.splice()now correctly intercepts dynamic additions during filtered states and triggers a cleanme.filter()projection rebuild without corrupting the O(1) maps.- Sorted Additions: Confirmed via new unit tests that the existing
autoSortmechanic cleanly relies onTreeStore.doSort()to handle positional insertion for sorted tree stores.I will close this ticket now.
tobiu closed this issue on Mar 10, 2026, 11:14 PM
When a new child node is dynamically added to a
TreeStoreand its parent is already expanded, thesplice()method fails to correctly project this new child into the flat_itemsarray at the correct hierarchical index.Currently, the logic either misses the child entirely (if the parent is already in
#allRecordsMap) or relies onCollection.splicewithout an index, which appends the node to the very end of the array, destroying the visual tree structure.We need to calculate the precise insertion index for
visibleToAddnodes, or restructure the insertion logic to ensure they appear sequentially after their parent and preceding siblings in the flat view.