|
|
|
|
|
|
by jxm262
3963 days ago
|
|
|
> Flux is also quite verbose, which makes it inconvenient for data state, state that is persisted to the server. We currently use a global Backbone model cache for data fetching and saving but we’re also experimenting with a Relay-like system for REST apis. (Stay tuned for more on this topic). What do they mean by this? I _think_ I've been doing something similar on my projects lately. Using Meteor as my backend pub/sub model, and React.js as my front end. Ties together pretty nicely although there's a range of other issues I'm still trying to work out (1 test frameworks for both React and Meteor code, etc..) |
|
|
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.