Dev Tools: Draw the slot flash where the item ended up - #2303
Merged
Conversation
`#buildItem` inserts a new item in front of the first one already there and announces it from that position, and the index puts it in its real place afterwards. The flash measured the item the moment it heard about it, so an `item-added` on a collection drew over whatever sat at the top of it. On the inline-edit table that is the first row every time, whichever row was actually added. Measuring on the next task instead reads the position after the whole batch has settled, ordering included. A microtask is not enough, since the reordering runs in the same task as the announcement. An item on its way out is the one case that cannot wait. `#dropItem` announces before it deletes the range, so a removal is still measured while its markers are in the document. This also gets the flash off a nested slot inside a freshly built row measuring zero by zero, since that slot has no box until the row it lives in is placed.
An item flash fills the row that changed, and any slot inside that row draws its own flash on top of it. On the inline-edit table the row is mostly one input, so the blue value write covers the green fill almost entirely, and the one thing the flash existed to say, that a row was added, is the part you cannot see. An item update now also outlines the collection it belongs to. The outline is dashed and unfilled, so it says where the collection is without competing with whatever is drawn inside it, and it takes the colour of the operation: green around an addition, red around a removal, the same colours the fill already uses. It sits under both the fill and the label by z-index, so nothing it frames is obscured by it. Only an update that carries an item draws one. A plain value or branch write is not about a collection and gets nothing.
github-actions
Bot
added
typescript
marcoroth
added
the
reactivity
|
View your CI Pipeline Execution ↗ for commit 50e95bc
💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗ ☁️ Nx Cloud last updated this comment at |
marcoroth
enabled auto-merge (squash)
August 19, 2026 23:33
marcoroth
disabled auto-merge
August 19, 2026 23:33
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow up on #2299 and #2300. With the flash drawing again, and telling a branch swap apart from a value write, what it says about collections is the part still worth fixing.
An
item-addeddrew over the wrong row.#buildIteminserts a new item in front of the first one already there and announces it from that position, and the index puts it in its real place afterwards, so the flash was drawing where the item was at that instant instead of where it ended up. On the inline-edit table that is the first row every time, whichever row was actually added.Measuring on the next task reads the position after the whole batch has settled, ordering included. A microtask is not enough, since the reordering runs in the same task as the announcement.
An item on its way out is the one case that cannot wait.
#dropItemannounces before it deletes the range, so a removal is still measured while its markers are in the document. That is the only operation left drawing synchronously.This also gets a nested slot inside a freshly built row off measuring zero by zero, since a slot in a row that has not been placed yet has no box.
An item update now also outlines the collection it belongs to, dashed and unfilled so it never competes with what is drawn inside it, in the color of the operation.