Related: #14512

The data module includes a persistence plugin which can be used by data stores to persist state values to browser storage.

https://github.com/WordPress/gutenberg/tree/master/packages/data/src/plugins/persistence

In the block editor, this is used in a few stores to persist preferences (e.g. toolbar placement, "new user experience" tips, etc).

Due to the transient nature of browser storage, this persistence is not as sticky as it is expected to be, including: switching browsers (unique storage between browsers), or using private browsing tabs (storage cleared between sessions), or the same user across a network of sites (storage unique by domain).

Proposal:

Preferences should be persisted as user meta. Given the WordPress-agnostic nature of the @wordpress/data module, this should be implemented in such a way that another environment could substitute their own (assumed asynchronous) persistence mechanism.

Specific details:

• Add a new option onChange to the plugin interface (Edit: This should not be necessary, see Persist user's editor preferences to database rather than local storage #15105 (comment))
  • Called when persisted value is set
  • Assigned in WordPress where currently opting in to the plugin
• Implementation of the onChange should communicate with the users REST endpoint, updating using the meta field
  • It will be required to register this meta as exposed to the REST API to be able to interact with it (show_in_rest)
• To populate the persisted value for use in the browser, it could be done with an inline script registered server-side to read from the user meta and assign to localStorage with the value on the storage key used by the persistence module