> In practice, this is virtually impossible to get right
Somehow every other JS frontend framework manages to hook into the History API just fine?
replies(5):
Somehow every other JS frontend framework manages to hook into the History API just fine?
I didn't realize that this will make the back button effective unusable, because the redirected url will still be in the history unless you manually redirect with a bare component. Hence whenever someone used back, the redirect pushed them back to the route they just left. I just used it as I came from a backend perspective, where redirects are fine as there is a delay between the request and the redirect, giving the user the time to just double press back... Obviously not so with a JS redirect.
I believe that continues to be an angular Anti-Feature to date.(Just checked, they still have it in their docs - without the ability to surpress the redirected history entry as far as I can see)
A few examples of the top of my head:
when urls have changed,
when a resource/entity has been deleted,
when you wish to provide a unified entrypoint that sends users to another url so that you can easily change the redirection target in the future (i.e. redirecting a / to a /entities, so youre but blocking the / path if you want to add a homepage/landing page later)
I don't think I'd help with posts though. They do indeed usually send back a redirect - but the post is likely still in the history unless the website send it as AJAX/without a history entry (basically via JS fetch() instead of form action=)