State Management II
Particularly when working in an environment like the browser, where some things are fast, and some things are really slow, it behooves us to set some state management ground rules, so we don't run into trouble as our app grows in size and complexity.
State Management IIWelcome Back
We'll remind ourselves of what was covered yesterday so it's fresh in our minds.
State Management IIDraft State & WeakMap
When a user spends some effort creating some state (i.e., a comment on a GitHub issue), it's important to protect them from losing it by way of an accidental swipe, press of the browser's back button, or a file drop in the browser's window.
State Management IIEXERCISE: Draft comments
We want to be able to make comments, and first we want to ensure that we don't allow users to accidentally discard their draft comments. Additionally, we need to ensure that drafts are always associated with the appropriate record
State Management IIPersisted State
You're no doubt familiar with persisted state, and using ember-data to help you manage it. However, when doing anything asynchronous, we have to keep context and life cycles in mind.
State Management IIEXERCISE: Saving comments
When a user wants to save a comment, it should be persisted to the API. Please implement this feature and meet the following requirements
- Once a save has successfully completed, the appropriate draft state should be cleared
- Your solution must behave as expected in a high-latency environment
State Management IIUI State
UI State is often pertinent to the presentation layer only, is only relevant "in the moment", and can in fact be harmful if not discarded and given a clean start if a user leaves and comes back. You may be thinking that component member data is the tool for the job, but it's more nuanced than you think!
State Management IIEXERCISE: UI State
We have a little metadata area at the top of each record, and want to allow users to expand and collapse it to their heart's content! Implement this feature, and meet the following requirements:
- The expand/collapse state should not carry over from one record to another as we navigate around
- If we expand the metadata area on a record, then go somewhere else, and then come back, we should see things as we left them
State Management IILunch
Break for Lunch