fix(deck): scope poll activation + QR overlay to the right Slidev view#48
Merged
Conversation
Presenter mode renders the next-slide preview (previewNext) and the overview as live component copies. PollPanel ignored $renderContext, so the preview copy of the *next* question reclaimed activation on every SSE snapshot, fighting the on-screen panel — the active question flapped and appeared stuck until a manual refresh. Gate every activate/close POST on the render context (slide/presenter only); preview/overview render read-only. QR overlay was component-local, so toggling it in the presenter window never reached the audience window. Sync visibility across same-origin windows via a BroadcastChannel (useQrBroadcast) — the primitive Slidev's own state sync falls back to without a server. The free toggle is kept; the overlay is decoupled from the sign-in gate so the audience window renders it, and the channel is keyed per question so only the on-screen panel reacts. Adds unit coverage for the gate and the QR sync, plus presenter-mode e2e covering both (the previously-untested presenter/audience interaction).
slidev-results-cross-origin and slidev-question-switch both drive the same Slidev dev server and the same checked-in slidev-demo/data.ts (each beforeAll rewrites it with its own seeded slug/pollId), and deck sign-in mints a token for the user's most-recently-created poll. Run in parallel they raced: one spec's data.ts write and deck token bled into the other, producing the wrong slug in the QR overlay and intermittent 403 (token poll mismatch) on activate. Move the question-switch spec into its own project that depends on slidev-chromium so the two never overlap, while the voter specs keep parallelizing. Validated by running the full suite 3x at 6 workers with zero flakes.
|
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.
Two presenter-mode bugs, both from deck components being unaware of which Slidev view renders them.
Active question goes stale in presenter mode
Slidev mounts the next-slide preview (
previewNext) and overview as live component copies.PollPanelignored$renderContext, so the preview copy of the next question reclaimed activation on every SSE snapshot, fighting the on-screen panel — the active question flapped and looked stuck until a manual refresh.$renderContext(slide/presenteronly);previewNext/overviewrender read-only.QR opens only in the presenter window
The overlay was component-local, so toggling it in the presenter never reached the audience window.
useQrBroadcastsyncs overlay visibility across same-origin windows viaBroadcastChannel(the primitive Slidev's own state sync falls back to without a server).Tests