Can we make Ember respect the default behaviour of the back/forward button?

1

So apparently when you hit the back button, Ember will just reload the corresponding route for that request - same goes for the forward button.

Many browsers, however, implement something called the BFCache. Here is some further information about how it works. So when the user hits the back button on a static HTML page, actually the whole DOM of the previous page is read from cache instead of being rerendered from scratch (same with forward).

Besides the performance concerns, this is interesting for us with respect to form inputs. On a static page, when I enter some data into a form, click the “next” button and then go back, the browser keeps the state of all the input elements. This won’t work with Ember out of the box: Either you use a controller for the form inputs (which is a singleton), but that will keep the inputs around all the time, not only when pressing the back button, or you use components, and then you lose the input when pressing the back button. This could somewhat be handled manually by using a service + a reset method that is triggered in appropriate route hooks, but it is a lot of work and it still doesn’t distinguish between clicking the back button and navigation to the previous route via e.g. a link.

This is currently a great usability concern for us. Is there any work planned in this direction? Is something like that even doable?

2

Stuff that got thrown around in the slack channel about that topic:

1 Like
3

I handle this with an ember data model backing the form fields and manually destroy the model when the form has been completed or they move onto a segment of the app that would imply they’re done with this action. For me this has worked out quite nicely using a parent route above the bits of the app that I would want to keep form state for while navigating around.

Something like

routes:    
  wizard/step1
  wizard/step2
  wizard/step3

as long as the user stays in the wizard they can back and forward with form state maintained. As soon as they leave the wizard it destroys or saves the data.

1 Like
4

that’d work, but it’s a lot of manual work for something that works “out of the box” on static HTML pages.

5

@Fryie Did you have a chance to find a solution? Or maybe a place where it is discussed?

1 Like
6

Sorry, I didn’t have any luck. In the end, we just abandoned the idea, which is a shame because I think that’s very intuitive behaviour that shouldn’t be broken.

1 Like