Client: Let a branch be switched from the client - #2300
Merged
Conversation
The only code that reports a branch change is `#writeFragment`, and its one caller is `apply`, so a server payload is the only thing that ever reached it. `materialize` hands back a fragment and there was nothing public to install one, so a page that flips a branch on its own has to do the work by hand, with `update`, `rangeFor().insertNode` and `scan`. That works, and it reports a value write, because `update` is what announced it. Anything watching slot updates, the dev tools flash included, then paints a branch swap the same colour as a number changing, and the `branch` colour it defines is unreachable. `switchBranch` is what `#applyBranch` does with the payload taken away. It parks what is on the page before replacing it, so going back the other way needs nothing new, builds the branch it was asked for, and announces it as a branch. It answers `false` without touching the page when the branch asked for is already the one showing, or when it was never parked, which is the case that still has to go to the server.
marcoroth
added
the
reactivity
github-actions
Bot
added
typescript
|
View your CI Pipeline Execution ↗ for commit 3c473ee
💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗ ☁️ Nx Cloud last updated this comment at |
🌿 Interactive Playground and Documentation PreviewA preview deployment has been built for this pull request. Try out the changes live in the interactive playground: 🌱 Grown from commit ✅ Preview deployment has been cleaned up. |
@herb-tools/client
@herb-tools/core
@herb-tools/dev-tools
@herb-tools/formatter
@herb-tools/language-server
@herb-tools/linter
commit: |
marcoroth
added a commit
that referenced
this pull request
Aug 19, 2026
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-added` drew over the wrong row. `#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, 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. `#dropItem` announces 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.
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, which fixed the slot flash drawing nothing. With it drawing again, two things it was hiding became visible.
The first is that a branch swap never reports itself as one.
#writeFragmentis the only code that announces abranchoperation, and its one caller isapply, so a server payload is the only thing that has ever reached it.materializehands back a fragment and there was nothing public to install one, so a page that flips a branch on its own has to do the work by hand.switchBranchis what#applyBranchdoes with the payload taken away.