In this scenario, the application state is all located in the client, as it's a Blazor WebAssembly application. There's no shared Fluxor state at all, as each client has its own store.
If I were to add cross-client communication so that each client's state could be updated based on another client's actions, I don't think I would do it via Fluxor on the server. I would do it via SignalR on the server, and my "singleton store" would be a database.
User1 submits some change to the server (which gets stored in the database), and that process notifies the server's SignalR hub of the change. The SignalR hub broadcasts the change to all of the listening clients, which would include User2. And User2's listener then Dispatches the appropriate Action to update their Store and whatever UI changes are needed.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the kind words.
In this scenario, the application state is all located in the client, as it's a Blazor WebAssembly application. There's no shared Fluxor state at all, as each client has its own store.
If I were to add cross-client communication so that each client's state could be updated based on another client's actions, I don't think I would do it via Fluxor on the server. I would do it via SignalR on the server, and my "singleton store" would be a database.
User1 submits some change to the server (which gets stored in the database), and that process notifies the server's SignalR hub of the change. The SignalR hub broadcasts the change to all of the listening clients, which would include User2. And User2's listener then Dispatches the appropriate Action to update their Store and whatever UI changes are needed.