Skip to content

Be more conservative when adding states to History API / make back button useful again #942

@lentinj

Description

@lentinj

Related to #940 & #547

Stop filling History API with every event we find by considering the current state either "fixed" (user wanted to visit this one) or "transient" (user is scrolling around).

When setting state, if the current state is "transient", then replace it with the next state we want. Otherwise add the state as a new state in the history API.

So, in more detail:

  • Open treeviewer, the initial view is a "fixed" state
  • Scroll around, we add a second "transient" state to the history list (i.e. back will go to initial view)
  • Keep scrolling, we replace this "transient" state with your current location (i.e. back will still go to initial view)
  • Clicking a node / leaf / search result will replace the current "transient" state with a "fixed" state pointing at the OTT1
  • Clicking another node will add a second "fixed" state pointing at OTT2 (and back will go OTT1 -> initial)
  • Clicking on signposts is a "transient" view, so multiple signpost-clicks don't fill the back button with noise.

@jrosindell @hyanwong does this sound like what we were talking about to you?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions