feat(pinia-broadcast): use BroadcastChannel & SharedWorker for syncing states across windows & tabs #780
Conversation
…g states across windows & tabs
Summary of ChangesHello @nekomeowww, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a critical state synchronization challenge in multi-window/multi-tab environments, particularly within the Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces a new package, @proj-airi/pinia-broadcast, to synchronize Pinia store state across different browser tabs and windows using BroadcastChannel and SharedWorker. The implementation is solid, providing a flexible transport mechanism and graceful fallbacks. I've identified a critical issue in the state patching logic that could lead to state desynchronization, and a high-severity configuration issue that disables the plugin in the web environment where it's most needed. My review includes suggestions to fix these issues.
|
|
||
| applyingExternal = true | ||
| try { | ||
| context.store.$patch(() => Object.assign(context.store.$state, deserialize(message.state))) |
There was a problem hiding this comment.
The current implementation of patching the store state using Object.assign can lead to state inconsistencies. Object.assign performs a shallow merge and does not remove properties that exist in the local state but not in the incoming state. This can cause state to diverge between tabs if properties are removed.
For example, if the state in one tab changes from { a: 1, b: 2 } to { a: 1 }, other tabs will receive { a: 1 } but Object.assign will not remove the b: 2 property, resulting in an incorrect state of { a: 1, b: 2 }.
A more robust way to apply the state is to use store.$patch() with the state object directly, which performs a deep patch. The function passed to $patch should also receive the state as an argument if you want to mutate it manually, which is not the case here.
I suggest replacing the current patching logic with a direct call to $patch.
| context.store.$patch(() => Object.assign(context.store.$state, deserialize(message.state))) | |
| context.store.$patch(deserialize(message.state)) |
| pinia.use(createBroadcastPlugin({ | ||
| includeStore: ({ store }) => store.$id === 'chat', | ||
| disabled: import.meta.env.RUNTIME_ENVIRONMENT !== 'electron', | ||
| })) |
There was a problem hiding this comment.
The pinia-broadcast plugin is being disabled when the RUNTIME_ENVIRONMENT is not electron. For the stage-web application, this means the plugin will be disabled, preventing state synchronization across browser tabs, which seems to be one of the main goals of this feature. This condition was likely copied from the stage-tamagotchi (Electron app) configuration and is not appropriate for the web application. To enable cross-tab sync for the web app, this condition should be removed or adjusted.
pinia.use(createBroadcastPlugin({
includeStore: ({ store }) => store.$id === 'chat',
}))
✅ Deploy to Cloudflare Workers (Preview) for stage-web ready!
|
…educe build output size
Description
stage-tamagotchiis multi-window / multi-tab architecture, means Chat window / Inlay window doesn't share the same Pinia with main window (which model renders at), this causes issue when syncing states between Pinia stores across windows.SharedWorkeror election mechanism like Kubernetes involves, multiple windows / tabs with TTS configured, both chat streaming, TTS will play in the same time across these windows / tabs.BroadcastChannel&SharedWorkerchannel implemented for syncing states for windows / tabs first, then we should have another Pull Request, introduce another plugin or option to distinguish those Pinia stores with only one instance live, and useSharedWorkerto dispatch messages only for the first constructor caller.Linked Issues
Additional Context