TL;DR: The basic setup could work something like this:
Event listeners on the Login API dispatch actions to the background Redux store.
UI views request initial local Redux state from background script on init.
Middleware installed in the background store relays actions to message ports on open UI views.
Relayed actions are dispatched in local UI stores to maintain sync.
More background:
The addon is composed of a background script, a panel UI, and a full-tab management UI. Currently, each of these pieces has its own data management code - the background has a datastore.js, and the two UI views have variant Redux stores.
A single Redux store module could be shared between all parts of the add-on. There, we could define one common set of actions and a data store modeled after the Logins API (ala #21). Redux actions map well to messages, which also reduces complexity between background and UI views.
This seems like a neat, low-priority idea for enhancement. Filing an issue to solicit poking holes in it. A few to start:
If it really is a single Redux store implementation, there will need to be UI state related data in it that's not directly related to Logins API data. (e.g. current selected item in full-tab management view)
Are there performance or memory concerns in a Redux store? (I'm thinking not significant concerns, but I could be mistaken)
TL;DR: The basic setup could work something like this:
More background:
The addon is composed of a background script, a panel UI, and a full-tab management UI. Currently, each of these pieces has its own data management code - the background has a datastore.js, and the two UI views have variant Redux stores.
A single Redux store module could be shared between all parts of the add-on. There, we could define one common set of actions and a data store modeled after the Logins API (ala #21). Redux actions map well to messages, which also reduces complexity between background and UI views.