History integration

[danielkcz]

Definitely digging the idea, awesome work! What about the ability to navigate back or even further in history? Or being able to block navigation to eg. show question about saving a form. I've actually made hook version of a Prompt component which turned out to be fairly easy.

function usePrompt(when, message) {
  const { history } = React.useContext(Router.__RouterContext);

  React.useEffect(() => {
    if (when && !context.staticContext) {
      return history.block(message)
    }
  }, [when, message])
}

Would you be interested in history integration of this project or is that out of the scope?

[Paratron]

I don't exactly know what you mean by "history integration", but I think I might have understood two things:

Being able to navigate back in browsing history through the router

Going back in the browsing history is something only the user should do. There is no point for a program logic to do so. If you want to go "back" from a product detail page to the overview for example, you simply navigate "forward" to the overview. Going back would only confuse the user because when he moved from product detail to overview and clicks "back" in his browser, he won't get to the product details again. This is bad.

Preventing the user to navigate away from a certain route

This one, I am not sure about. It is very annoying if an application does this. But its also annoying if you lose some data because you just navigated away without saving. I would advise to preserve the data in sessionStorage and offer the user to restore it if he comes back to the form in question. This is more userfriendly than slapping a confirm into the face when he intentionally tries to navigate somewhere. In the rare case that he unintentionally moves away, the data is secure.

[danielkcz]

Going back in the browsing history is something only the user should do. There is no point for a program logic to do so. If you want to go "back" from a product detail page to the overview for example, you simply navigate "forward" to the overview.

I would argue about that. Simply imagine PWA application running on a tablet. There is no browser back button. You want to have that button in your UI.

I would advise to preserve the data in sessionStorage and offer the user to restore it if he comes back to the form in question.

As much as the ideal that sounds, in multi-tenant application it can also mean ugly collisions. You start editing a form, don't save the data. Later someone else edits the same thing, saves it. You come back even later and you still have old data there and upon saving you would overwrite previously saved data. Collaboration is always ugly, no argue there, but I would rather prevent some scenarios, not to give tools for more problems. Even though it means worse UX.

[Paratron]

The secound part would be solved through #10

[Paratron]

Closing this in favor of #10