Imagine you’re taking an online exam, and spend 2 hours answering questions, then your system decides to turn itself off to install updates, or your browser crashes, or your cat walks on the keyboard and reloads the page. Everything is lost when you go back to the page. Time to demand a refund and use another company.
How, as Ember / Ember.data developers, should we prevent this from happening? How do we get robust state in the client?
Another similar example is this one about shopping carts
Use the URL
The current situation seems to be assuming everything in the app can be rebuilt from the URL, either by query params or by re-loading external data.
I don’t think the URL and query params are appropriate for large amounts of data. I also find query params really ugly when they’re not used to control a query, but that’s personal preference.
Sending all updates immediately to the server isn’t the architecture we want. We want to use the client’s local storage, for client robustness and latency, and lower server throughput.
Store locally, commit later
Instead we want to use client state to roll those requests into one big update later, once the data is ready to submit (once the exam is completed).
In practice that means storing the exam responses (e.g. a hash of question ids and selected answer ids, or text) in the client until the user clicks mark exam.
A survey or feedback form might work differently here, wanting to report data to the back-end immediately, to allay abandonment, but we don’t need that, and can have a single post request.
Ideally in this case the ember store would not be flushed when the page is reloaded. Since it is, I’m trying to find a good, or at least working, alternative.
Make pending models with the local storage adapter
I’m trying now, after failing with ember-local-storage, to build the exam (form) using normal ember-cli/ember.data pages and models, with the ember.data localstorage adapter, then once the user finishes the exam it’ll build up and submit a set of duplicate (or very similar) models backed by the rest-adapter.
This seems like a lot of extra work? Is it normal?
Could ember.data, or a new adapter, handle it?
It seems like ember data models have two states: ephemeral (updated or new) or saved-to-backend? There could be a 3rd state: persisted on client (local storage), which could replace the ephemeral state in the same way that some apps write to disk instead of to memory?
In my case that’d mean an adapter pointing at the rest api as normal, but also saving itself to local storage (and being able to restore from it) up until submission to the rest api. Whether this should be automatic (work by default) or invoked by the app (more performant) isn’t clear, but both are probably possible?
Does that sound like it could work, or maybe someone has another idea? Or there’s an addon already?
Does it matter?
Ember’s marketing says it’s for making apps that compete with native clients.
I’d argue that native clients use local storage to be responsive, with good performance and availability despite network or server problems, and patching over reloads and browser crashes is part of this?
I seem able to answer a lot of my own questions by saying “store in the server”, but that’s forcing one architecture on all applications. Is that expected, or is this a real problem?