Best practices for building large React applications
blog.siftscience.com
Best practices for building large React applications
1–10 of 26 posts
Re: Best practices for building large React applications
#2> 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..)
Re: Best practices for building large React applications
#3Some 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.
[0] http://aeflash.com/2015-02/react-tips-and-best-practices.htm...
Re: Best practices for building large React applications
#4Here's the link to last time it was discussed (3 months ago): https://news.ycombinator.com/item?id=9515392
Re: Best practices for building large React applications
#5> 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/…
The 'vanilla' implementation of Flux is very verbose, due to its declarative nature
The Relay system they're talking about is in reference to http://facebook.github.io/react/blog/2015/02/20/introducing-..., which is how Facebook manages data fetching at the component level.
Re: Best practices for building large React applications
#6> 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/…
The 'vanilla' implementation of Flux is very verbose, due to its declarative nature The Relay system they're talking about is in reference to http://facebook.github.io/react/blog/2015/02/20/introducing-... , which is how Facebook manages data fetching at the component level.
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.
Thanks for the link! Wasn't even aware of Relay.
Re: Best practices for building large React applications
#7Any examples of good tile-based board games written in React (or other JS frameworks)?
Re: Best practices for building large React applications
#8Some 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…
Also, if it is in a "did update" method, doesn't this imply that the components state has already changed?
Re: Best practices for building large React applications
#9"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.
Re: Best practices for building large React applications
#10> 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/…
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.