"Thinking in React" blog post

[petehunt]

I haven't set up my new ruby env yet so this is not ready for commit, but this is a first pass at a blog post about how to think while building a React app. Looking for feedback! :)

[chenglou]

Overall I really like this post! =)

[jessep]

I believe I am your intended audience (read the docs, familiar with basic mechanisms, haven't built much in it yet, want to see big picture). I really like the post, it's super helpful.

I had a question here you might want to address: how to handle changes to the product list coming in from the server, assuming they happen. Most apps with any realtime component are going to have this issue. Maybe this is beyond the scope of the article, but it stuck out to me.

My assumption is that I handle the product list changes outside of react, in my own data layer, and pass the whole dataset it in as a prop to the root component, re-rendering whenever the product list changes? Is that right?

[petehunt]

Yep, that's one great way to do it. But let's think of how we'd do it with only React.

First, let's add the additional requirement that the initial page load needs to show the products (i.e. no extra AJAX call on first load). This makes the example more complex / educational.

The new minimal set of state now includes the current set of products (currentProducts), since this could change over time.

For the initial load we want to initialize currentProducts to the JSON that the server sent down with the page. So we change the products prop to be called initialProducts and copy it into state in getInitialState() (i.e. return {currentProducts: this.props.initialProducts})

Then we can use React's lifecycle hooks (somewhat outside the scope of this post) to start a setInterval() that polls the server. When the server comes back with new data, just do this.setState({currentProducts: responseFromServer}).

Make sense? Great feedback, thanks.

[jessep]

Yeah, that makes sense, except I'd assume the api would return incremental updates to items like {'operation':'edit', 'id':'basketball121', , 'price':539}. But your example is still illustrative, the callback for the interval would just merge that change into the currentProducts and set state returning the whole thing.

If I had a product list of 50K items, say they're nested (which is what my actual product is often like), would I still setSate on the entire list, or would I want to come up with a strategy where I can setState on individual products somehow?

[petehunt]

You're asking that because you're concerned about performance, right?

The thing that makes React really cool is that you only add optimization hints rather than refactor your code to optimize perf. So for your example: what's the most logical way to write your app if you didn't care about perf? It would be to still setState() on the entire list, right?

If it becomes slow, you can override shouldComponentUpdate() on your list item to get your perf where you want it to be. This should be a whole separate blog post though :)

[jessep]

Ha, yeah, that's why I was asking. Anyway, I'll stop hijacking the thread :)

It's a great post. Like @chenglou I'd recommend inlining a few pieces of code.

[petehunt]

No, these comments are super helpful. Maybe we should work some of what you said.