My first project with React was a mess, mostly because of Redux. Not because it's bad, but because the lead dev was adamant about using something Flux like. First we had Flummox, than he rewrote everything in a week with Redux, that was 2 years ago, before Redux had sane async helpers.<p>In my current project (where I'm the lead, haha) I'm trying to got state/props all the way.<p>I think for most apps it's more than enough AND it's easier to get started for new devs.<p>React is really easy. I mean coming from Ember and ExtJS, its API is a walk in the park and you can get really far without extra state management.<p>One thing that is important for this approach, minimize nesting.<p>You don't want to pass down everything from the app, to the screen, to the list, to the item. etc.<p>Instead of doing:<p><pre><code> <List items={items} />
</code></pre>
do it like that<p><pre><code> <List>
{items.map(i => <Item item={i}/>)}
</List>
</code></pre>
No nesting of screens (top-level components), no (hidden) nesting of components. This may seem kinda strange, because the first example has no dependency to the Item component, but it gives the component that uses the List direct access, which simplifies props-passing immensely.<p>This doesn't work for all apps, but it's a good starting point.<p>I ended up with 2 folders, screens and components, that are both simply flat lists of component files.
I'd rather use Redux without React than React without Redux. Sure there's some boilerplate but we use typescript so the redux boilerplate seems trivial in comparison.<p>Redux keeps your app _simple_. That's not the same as easy. It means that you can reason about your app as it grows and new features are added. When you run into problems like: this page is taking too long to load because we do calculations x, y and z on the server to push the data to the app. But z takes forever to compute and makes the initial page load painful. With Redux, you can move z to an async endpoint and just load x and y on page load (put the component that needs z in a loading state). Then, fire an ajax request when the component mounts to get z. When that call returns, it updates your store and the component that needs z transitions from loading to loaded.<p>I took me a couple of hours to do the above in a Redux app and decrease the page load from 2 seconds to 300ms. And it didn't add complexity to the app that would make it difficult to maintain. I don't even want to think how long that refactor would take if the state had been managed with React.<p>And ... don't even get me started on how easy -- and fast -- it is to test a Redux app. Zero side-effects means zero setup and teardown between specs.
The rush to use Redux for every React project is one of the most annoying parts of the React community; using a tool just to use it, before understanding if you need it or not. This article summarizes a lot of good points.
As usual, this is an excellent article by Robin. Well-written, and full of great information.<p>It's worth noting that both the React and Redux teams (including Dan Abramov and myself) agree that you should focus on learning React first, and _then_ learn Redux. That way there's fewer new concepts and terms to learn at once, and once you understand React, you'll have a better appreciation for what kinds of problems Redux can help solve. That's not to say you _can't_ learn them both at once, just that it's the suggested approach that will work best for most people.
As a general rule do not use `this.react` inside `setState({ ... })` - this will cause you problems eventually due state updates being async.<p>If you need to use state to set new state, use functional callback instead - <a href="https://facebook.github.io/react/docs/react-component.html#setstate" rel="nofollow">https://facebook.github.io/react/docs/react-component.html#s...</a>
I wish React would come with a standard way to handle Ajax (or a convention or semi-standard library would emerge). <i>(Edit: "comes along" in the sense that immutability-helpers, redux and create-react-app come along with react. I'm not proposing to add anything to the react module. I'm not the world's best expert on react, but before downvoting can you please assume I know a little bit of what I'm talking about?)</i><p>Something that:<p>- Can fetch JSON according to criteria from an API<p>- Caches stuff locally (just in memory, or in local storage) in case of duplicate calls<p>- Deals with multiple concurrent calls, and merge them (e.g. fetching 1 and then 2,3,4 before 1 finishes -> either cancel 1, or wait until it finishes, and then fetch only the last requested item.<p>- And all the stuff I can't think about right now, like cancellation and timeouts<p>Plug your pure component into one of these, tell it about your API, and you're done. It's really error prone to write these containers yourself. And I think Redux doesn't really help much with Ajax.
IMHO Redux is a heavy, clunky and awkward practice that is only holding React back.<p>My advice to anyone reading this forum is give MobX a try before deciding to commit to Redux.