View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007072||Anastasis||anastasis-webui||public||2021-11-04 23:20||2021-11-09 14:50|
|Reporter||Florian Dold||Assigned To||sebasjm|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Summary||0007072: browser history integration|
|Description||There are various possible behaviors here:|
(a) The navigation inside the anastasis SPA is independent from the browser navigation, and the back button always goes to the page visited before the anastasis SPA
(b) the browser back button always goes back "hierarchically", i.e. it's always like pressing the back button inside the SPA
(c) the browser back button always goes back "historically", i.e. when in the UI we press "next", "back", "next", the browser history will record each of these steps
We should discuss these possibilities with Belen.
|Tags||No tags attached.|
One simple way I can think of is allowing the user to navigate free between state, two things can happen:
1.- is loading an upcoming state before is ready: instead of showing an "invalid state" message we can assume a "preview" screen to explain what the user will do when it reaches this state and how the previous state is needed to this become available.
2.- is loading an previous state: show a readonly state with a button "jump into this state" which will call a "goto" action in the reducer and a "go back where I left" button which will sync the history with the reducer current state.
pros i can think of:
* from (1) we use screen to show more information on how anastasis works for the curious one
* we allow random access to any state from the side bar
* from (2) if there is any validation to be done it can be placed into the "goto" action and add a notification "no you cannot go back into this action because XXXX"
* free navigation through almost all screen is possible
The screens that I'm thinking as navigable are the one that can be accessed from the sidebar, lets call them "principal screens". Others, like authorization method setup or a policy editing, are internal state from the principal screen and will be not reachable from links/history. IMHO I think this is ok for now.
||@belen what do you think?|