[guscost]

This is a guess, but it sounds like if a user opens some persistent record for editing, the data for that record (once loaded to the client) is not moved into a Flux store but is kept in a cache layer. Then the store would only contain the information that is necessary to render the UI.

My approach is to have a "mapper" module that is responsible for translating to and from API data transfer objects, and then an AJAX module that loads state into and saves state from the stores, using the mapper module. This means that all data the client may need to reference ends up in the stores, even if that data may not be displayed on the screen. However it eliminates the need for another cache layer on the client.

One question I'm still working through is whether a UI interaction with a low-level component should be allowed to cause state not typically included in that component to save to the server. In this case, maybe one Flux action would dispatch just to tell the stores to collect the needed data and then dispatch another action to save, or perhaps the stores would call the AJAX service directly, or the action creator could request the state from the stores and save it with the AJAX service immediately. I like how simple the "every step is a new action" approach is, but it could lead to a lot of extra functions that don't do much except move the data along.