Have you checked for existing feature requests?

• Completed

Summary

@asiloisad asked on Discord what the best way is for Pulsar windows to share data. That idea has come up a few times; here are two examples:

• As @asiloisad points out, tree-view allows the user to copy entries from one project window and paste them into another. Under the hood it uses localStorage to pull this off.
• The pulsar-updater package runs an application-wide task (checking for updates) and then needs to notify the user about it. The best option is probably to show a notification on each open window (as we currently do), but to make it so that all notifications are dismissed as soon as the user acts on any of them (as we'd like to do but have not yet implemented). To pull this off, we'd want each page to listen to some sort of central store that can tell it when another window's notification has been dismissed. This pattern would also be useful in the sync-settings package.

Since each Pulsar window is its own instance of a web page, there aren't many ways to pull this off. The most obvious one is the one that we already use: window.localStorage. That works somewhat well, but…

1. localStorage sets and retrieves strings, and built-in serialization would be a nice feature;
2. we don't get any reactivity — if one window sets a value, another window would have to poll at an interval to learn when that value has changed.

Problem 1 can be solved by writing a wrapper around localStorage and performing serialization and deserialization automatically. (This would limit what could be stored, but that's a good thing; we don't let people store whatever they want in atom.config, either.)

Problem 2 can be solved by… well, I'm not sure. One option would be to run a WebSocket server in the background and have each window connect to it. That way it can notify each window when a field has changed. It wouldn't necessarily need to manage, or even access, the data; it could just act as the courier for “hey, check for a new value at key foo” messages between windows. (The tricky part is running only one instance of the server no matter how many windows are open.)

Bonus points if it could work identically to atom.config in the sense of being able to observe any level of a hierarchical key path. For instance: one could set sync-settings.foo to 3 and would notify anyone who had asked to observe sync-settings.foo (whose change handler would fire with a value of 3) or sync-settings (whose change handler would fire with a value of { foo: 3 }).

If anyone's got ideas for pulling this off that aren't quite as half-baked as mine, do chime in.

What benefits does this feature provide?

Not having to deal with localStorage directly, plus not having to poll for changes to localStorage.

Any alternatives?

The StateStore class presents a different option (IndexedDB), but we've been cursing IndexedDB for a while now, and it'd leave us with the same two problems to solve.

Other examples:

No response