Some great ideas, especially the examples of breaking down UI into smaller components. Thanks for writing this.
I've been using Flux to manage pretty much all of the application state, and pass it to the top-level component and down through the tree of components as props. This idea was very well described in an older article[0]. I would add that this approach makes shouldComponentUpdate very important, since more of the tree is rendered on every change.
Your example of the dropdown state is a great counter-example where Flux is not necessary or even helpful, and in fact I've used the same example when explaining it myself.
One thing I'm not sure about is whether the save action should use a callback (or Flux ActionCreator), or whether it should be triggered by comparing the values in componentDidUpdate as you suggest. Making that behavior declarative is certainly appealing, but I'd be worried that an action like a save could be idempotent, with unpredictable side effects, and therefore makes more sense to be explicit/imperative? I'm not sure which one would be easier to work with at very large scale, and it looks like your application is larger than any of mine, so perhaps the declarative style works better. If anyone has more to say about this I'm curious to hear opinions.
I like me some React, but my only gripe w it is the synthetic events, which can result in a single model's state being updated by multiple listeners.
I have replaced synthetic events w event streams, and couldn't be happier w how much cleaner the code has become as a result of replacing setters with stream-combinators.
The architecture roughly follows Elm's Model-View-Update, by splitting each component into view.jsx and update.js.
1. Update contains the eventstreams (replacement for synthetic events), and are transforms them into update-streams.
2. The model combines multiple update streams to return a model-stream.
3. The view combines multiple model streams, and the subscriber at the end does a `setState` to trigger the re-render
Using streams also has the side-benefit of not needing the didUpdate, shouldUpdate etc lifecycle hooks.
> 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..)
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.
Oh yeah I get the part about flux being verbose :) Probably should have omitted that part and just asked about what they meant by the Backbone model cache.
"If you find yourself duplicating/synchronizing state between a child and parent component, then move that state out of the child component completely."
I have exactly one exception to this rule and I would love is someone could provide a recommended way to not make it an exception. Debouncing. For example, if you have a input field that lets you type a number for pagination, debouncing the change of that value with the displayed copy of it.
This is implemented with a debounced input field type that uses props to get and update the value, but maintains it's own state for what is displayed. It uses `componentWillReceiveProps` to stay in sync.
EDIT:
After re-reading, it looks like the author uses this exact same exception for the "select". This is considered UI state and should be fine.
never understood why React needed flux on top. Or does that mean React doesn't solve the problem it is supposed to solve on its own ? or flux should have been baked in react? never understand what flux was about anyway.
Flux is a way to organize interactions with data and business logic, so that React only has to worry about the UI. Specifically, it breaks down behaviours into functional streams that don't interrupt each otherr.
AFAIK (I have not worked with Relay yet) Relay is a data layer, (which currently flux handles already). Relay is component based, as opposed to flux, which handles data in a top-down manner.
As I understand it, when we implement Relay, flux will be relegated to handling UI behaviour and changes. So, React would handle DOM manipulation and rendering, Flux will handle user behaviour and changes to state, and Relay will provide the data.
I've been using Flux to manage pretty much all of the application state, and pass it to the top-level component and down through the tree of components as props. This idea was very well described in an older article[0]. I would add that this approach makes shouldComponentUpdate very important, since more of the tree is rendered on every change.
Your example of the dropdown state is a great counter-example where Flux is not necessary or even helpful, and in fact I've used the same example when explaining it myself.
One thing I'm not sure about is whether the save action should use a callback (or Flux ActionCreator), or whether it should be triggered by comparing the values in componentDidUpdate as you suggest. Making that behavior declarative is certainly appealing, but I'd be worried that an action like a save could be idempotent, with unpredictable side effects, and therefore makes more sense to be explicit/imperative? I'm not sure which one would be easier to work with at very large scale, and it looks like your application is larger than any of mine, so perhaps the declarative style works better. If anyone has more to say about this I'm curious to hear opinions.
[0] http://aeflash.com/2015-02/react-tips-and-best-practices.htm...