We added a new "dockLocationButton" configuration in a previous ticketn
Now, we want to enhance the menu that appears to have a "Save" button or "Set as Default" indicator.
- or to potentially save automatically as an implicit effect of the user changing the docker position.
More significantly, we want to do this via an abstraction so that the implementation is not tied to a specific backend database API.
We aim to leverage the extensions strategy, or possibly a pub/sub strategy so that the action of persisting a preference change related to position change is well defined but decoupled from the Scaffold.
There is already an es-preferences extension which integrates with a specific backend API for our group of projects.
- We may enhance this extension to integrate with the "save location preference" option.
- But our solution should be such that the
es-preferences can be replaced by some alternate implementation to integrate with an alternate backend.
TBD: We want to design a mechanism for deciding when that Save button should be present, because not all deployments of the Scaffold will have a preferences backend available.
TBD: We might just always have a default Preferences API available, that uses localStorage, so we'll discuss when we get this far.
TBD: if we do always have the save button, maybe we override localstorage when there's an extension present for a backend.
TBD: We will exclusively interact with preferences via the pub/sub, which allows for an arbitrary preferences backend to be dropped in that saves the prefs.
above bullets will be designed when we get here... simple enough, but needs more definition than I can put in this ticket.
When the user clicks the "Save" button, the Scaffold should use a pub/sub message to request that the preference be saved.
We will need to make sure that prefs extension is implemented fully enough to give feedback about whether the preference was saved.
TBD: Might make sense to split this ticket into several parts.
one part for updating the preference extension that interacts with the backend and local storage
one part for the actual save button and the pubsub
Reference: 11567
We added a new "dockLocationButton" configuration in a previous ticketn
Now, we want to enhance the menu that appears to have a "Save" button or "Set as Default" indicator.
More significantly, we want to do this via an abstraction so that the implementation is not tied to a specific backend database API.
We aim to leverage the extensions strategy, or possibly a pub/sub strategy so that the action of persisting a preference change related to position change is well defined but decoupled from the Scaffold.
There is already an
es-preferencesextension which integrates with a specific backend API for our group of projects.es-preferencescan be replaced by some alternate implementation to integrate with an alternate backend.TBD: We want to design a mechanism for deciding when that Save button should be present, because not all deployments of the Scaffold will have a preferences backend available.
TBD: We might just always have a default Preferences API available, that uses localStorage, so we'll discuss when we get this far.
TBD: if we do always have the save button, maybe we override localstorage when there's an extension present for a backend.
TBD: We will exclusively interact with preferences via the pub/sub, which allows for an arbitrary preferences backend to be dropped in that saves the prefs.
above bullets will be designed when we get here... simple enough, but needs more definition than I can put in this ticket.
When the user clicks the "Save" button, the Scaffold should use a pub/sub message to request that the preference be saved.
We will need to make sure that prefs extension is implemented fully enough to give feedback about whether the preference was saved.
TBD: Might make sense to split this ticket into several parts.
one part for updating the preference extension that interacts with the backend and local storage
one part for the actual save button and the pubsub
Reference: 11567