[RFC] Add persistence to the UniversalStore API

[Sidnioulz]

Summary

We sometimes need to persist user choices in a Storybook instance. For example:

• Interactions autoplay should be disabled for some user populations, and the choice should persist
• Addons like https://github.com/mrginglymus/storybook-addon-persona need to persist user preference to make sense

This can all be achieved in localStorage, but it's not always what we want:

• localStorage cannot distinguish multiple local Storybook instances as they use the same port
• This leaves the responsibility of connecting localStorage to the store to callees

If the store itself had a persistence option, it'd replace setAddonState's own persistence nicely. It'd provide a better DX and it could try to somewhat distinguish local instances. Besides, the addon state API is deprecated (and apparently not so stable any more, @mrginglymus reported he didn't manage to use it).

Problem Statement

This can all be achieved in localStorage, but it's not always what we want:

• localStorage cannot distinguish multiple local Storybook instances as they use the same port
• This leaves the responsibility of connecting localStorage to the store to callees

If the store itself had a persistence option, it'd replace setAddonState's own persistence nicely. Besides, the addon state API is deprecated (and apparently not so stable any more, @mrginglymus reported he didn't manage to use it).

The store could attempt to distinguish local instances based on FS information (path to main), possibly Git info if we already have a Git-related dependency. It could at the very least reuse the brandTitle or brandUrl (https://storybook.js.org/docs/configure/user-interface/theming#create-a-theme-quickstart) to dedupe instances that aren't at all about the same product.

The store would also directly read/write and handle errors and default values, so callees would not need to do this synchronising themselves.

If we think the risk of returning corrupted state is too high, we could allow callees to version the content being persisted directly in the API, so that switching between branches in a project resets state when the version is different, instead of returning state with a different API that could lead to hard-to-debug errors.

Non-goals

No response

Implementation

I don't know the universal store API well enough to outline an implementation :(

Prior Art

We used to have persistence in the addon state API, so we had recognised the value of it back then.

Deliverables

1. Add persistence support to the universal store
2. Build a v1 of instance distinction
3. Document the persistence option in the store's own doc (does not exist yet?) and in the addon writing docs

Risks

• There might be good reasons why the previous API was deprecated, which I'm not aware of
• If we don't do a good job of handling errors or reuse of store across multiple instances, end users might end up with corrupted state; store callees might need help in building the mental model that the store content may come from a different instance

Unresolved Questions

• Technical feasibility
• Whether our approach to instance distinction may lead to corrupted state for our callees

Alternatives considered / Abandoned Ideas

No response