fix(toolbar): compute button state on first render

[makhnatkin]

• Toolbar buttons get their real state on the first render. Before this, they appeared enabled until an effect ran after paint.
• A remounted toolbar no longer shows the Undo and Redo buttons as enabled in a screenshot.
• The punctuation boundaries test waits for the split preview content before taking the screenshot.
• The fixed pause before the screenshot is removed.

🤖 Generated with Claude Code

Summary by Sourcery

Render toolbar action states synchronously and make visual-test synchronization content-based.

Bug Fixes:

• Compute toolbar action states during render so buttons display the correct enabled and active states immediately, including after remounts or editor changes.

Enhancements:

• Track committed toolbar state snapshots for update events while avoiding stale or abandoned render state.

Tests:

• Add unit coverage for initial, changed-editor, and event-driven toolbar action state updates.
• Make the punctuation-boundaries visual test wait for preview content instead of using a fixed delay.

[gravity-ui]

[gravity-ui]

[makhnatkin]

@sourcery-ai review

[sourcery-ai]

Hey - I've found 1 issue

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="packages/editor/src/toolbar/hooks.ts" line_range="31" />
<code_context>
-        active: false,
-        enabled: true,
-    });
+    const [state, setState] = useState(() => getActionState(editor, {isActive, isEnable}));
     const stateRef = useLatest(state);

</code_context>
<issue_to_address>
**Toolbar shows stale button state**

When a mounted toolbar receives a different editor or changed action predicates, including a same-length replacement list, `useState` retains the previous state, and a same-length list can pass the `state.length === actions.length` check. The passive effect applies the new state only after paint, so the toolbar briefly shows the prior enabled or active state.

Recompute or reset the action state synchronously when the editor or action inputs change, rather than waiting for the passive effect.

Also at `packages/editor/src/toolbar/hooks.ts:59-61`.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

[makhnatkin]

@sourcery-ai review

[sourcery-ai]

Hey - I've found 1 issue

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="packages/editor/src/toolbar/hooks.ts" line_range="36" />
<code_context>
+
+    // Computed during render, so changed props never show the previous state.
+    const state = getActionsState(editor, actions);
+    const latestRef = useLatest({editor, actions, state});

     useEffect(() => {
</code_context>
<issue_to_address>
**Committed toolbar keeps stale state**

When a concurrent render with different editor or action props pauses, then the still-committed editor emits an update matching the work-in-progress state before that render is abandoned, `latestRef.current` exposes the speculative `editor`, `actions`, and `state` to the committed update listener, so `onUpdate` compares the committed editor's update against that snapshot, skips `rerender`, and leaves the toolbar showing stale button state.

Publish the listener snapshot only after the render commits, so abandoned work cannot replace the committed comparison state.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

[makhnatkin]

@sourcery-ai review

[sourcery-ai]

Hey - I've reviewed your changes and they look great!

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook