First of all, don’t worry about “anti-patterns”, just do what makes sense to you as long as you don’t ship too many bugs. There is a whole industry (educational content, conferences, consulting) revolving around selling “best practices” and cures for “anti-patterns” so my advice is to be chill about them ;-)

As for your specific question, it depends. If most of my network requests don’t end up as useful actions changing the state, I wouldn’t use middleware for them, and just do them directly. However if most of them change the state, but a few don’t, I might use middleware for consistency. Don’t worry about “anti-patterns” and use your best judgement.

Create React App + a cool idea for an app :)

Build an app with React itself. When it's large, you might notice some components get extremely large and buggy. This is a good point to perhaps introduce some Redux into it. Most importantly, learn things as you need them to build an app, don't try to learn everything at once. https://github.com/petehunt/react-howto is a good guide. github.com/facebookincubator/create-react-app is a good way to get started.

I think Redux DevTools are pretty cool.

Some favorites of mine (some stable, some crazy)

https://github.com/yelouafi/redux-saga
github.com/redux-observable/redux-observable
https://github.com/cerebral/redux-action-tree
https://github.com/philholden/redux-swarmlog
https://github.com/markdalgleish/redux-analytics
https://github.com/rangle/redux-segment
https://github.com/stoeffel/redux-elm-middleware

Speaking personally, I am a big fan of Immutable. The reason I haven't used it more is that it's a bit awkward to navigate a codebase that mixes immutable and non-immutable values. It's also awkward having to use .get() to unwrap an immutable value. To fully experience the benefits of immutable data, you'd need first-class language support so that it's possible to use it seamlessly everywhere.

I think it's a great fit for both Redux and React. One problem, though, is that it makes things like serialization and debugging a bit of a pain—again, because it's not a feature of the language.

So while I don't use Immutable everywhere in my apps, it's great for those areas in which it does work.

I think React Router v4 preview looks pretty good, and I'd recommend using it when a stable version is out. You can read about it here: https://github.com/reactjs/react-router/tree/v4.

I use React Router. I've had quibbles about some of its API decisions in the past, but on the whole it has served me very well. I'm really excited about the upcoming API in version 4!

In my view, routing isn't a central piece of most React apps, so I wouldn't worry too much about whether your particular routing solution is the absolute best one out there. I will say, though, that the React Router team is smart, hard-working, and committed to solving the community's real world problems.

Hi! I’m not quite sure what you mean by transitions.

If you mean rendering a different component when an event fires (e.g. user clicks a button), normally you would call setState() from the button’s event handler, and render something else. Here is an example: https://jsfiddle.net/uokq5ggq/. Thinking in React is a good guide explaining how state works in React.

If you mean animations, I suggest to check out React Motion as well as watching this talk.

I realized it was getting popular when it was still a proof of concept for my upcoming talk and had about 300 stars. I went to bed and woke up next morning to a list of 15 small Redux examples that popped up on the net. It was very confusing because we didn’t really document the library well at the time, and I didn’t expect anyone to start using it yet. That’s when I knew something was happening. Later I gave my React Europe talk, and it just kept growing. This was when I knew I’d better document it, so I raised some money on Patreon, and worked on examples and documentation for a few months.

I was excited to be solving problems I was interested in, such as hot reloading and time travel (https://www.youtube.com/watch?v=xsSnOQynTHs). I am also continually impressed by all the amazing work happening in the ecosystem (redux-saga, redux-observable, redux-devtools-extension, etc). It’s humbling to have played some part in this.

I try to not get emotionally invested into Redux or its ecosystem because once something is large enough, it takes on a life of its own, and you can just watch it happen and maybe sometimes correct its course. I try not to feel guilty about the churn experienced by people who took Redux too seriously and tried to use it even when it didn’t work well for their use case. I also try not to get upset when somebody bashes Redux. I understand that now that it’s big, many people are going to have to use it against their will, or have to learn it because it’s trendy, and bump into many abandoned experiments or frankly bad ideas in the ecosystem. Overall I’m very grateful to the community who built on top of Redux, and if it helped move some amazing techniques from functional programming closer to the mainstream audience, it makes me happy.

My dream job. (No, seriously, it was my dream since about maybe two years ago, before I sent the first PR.)

In terms of what it's actually like, our work is generally pretty visible. Lately I've been working on Create React App because a lot of people in the community are frustrated by complicated tooling. I also send some PRs with improvements and bugfixes to React. For example I added a Chrome Timeline integration to the performance tooling that will be out in 15.4.0.

I live in London so I talk to the team once a week via a conference call to sync up on tasks and priorities. I try to publish our meeting notes on https://github.com/reactjs/core-notes.

Yes! GraphQL is amazing, as anyone who has played with a GraphiQL playground can attest.

To really take advantage of GraphQL in a React app, you need some sort of centralized store for normalizing and caching all your data. At OpenGov, where I previously worked, we used Relay in production since September of last year. It's a fantastic solution for declarative data fetching. I don't think we ever had a bug related to data fetching hit production.

There is some awkwardness when you first get started with Relay, particularly around mutations, which still sometimes confuse me. I occasionally hear from people who are turned off by the verboseness of some of Relay's APIs. If that's your reaction, I encourage you to look past it and give it a shot. In my experience, Relay offers an incredible number of features for just a bit more typing. Relay 2 (an upcoming rewrite of Relay's core) will solve some of these problems as well, in addition to some great performance improvements.

Many products at Facebook use Flux—naturally, since Flux was invented here internally :)

Redux has started gaining some adoption as well. As far as I can tell, it's being used in a few dozen places, including a new implementation of the blue navigation bar that we've been testing.

I usually say no. Component-local state does not belong in Redux because Redux is a global store. It has no awareness of a component's lifecycle, and it's very easy for multiple components to accidentally write to the same slice of Redux state.

Instead, we're looking for ways to make React's state API more functional and Redux-y, so people are less tempted to abuse Redux :)

Valid exceptions include when state serialization/deserialization is really important, or if you want to use the Redux DevTools. Though I think there are better solutions to these problems out there, waiting to be implemented.

I would say that some aspects of Redux are similar to Elm Architecture (https://guide.elm-lang.org/architecture/). In particular, Redux reducers are similar to "update" functions in Elm, and Redux combineReducers() is a helper for a pattern that is also used for creating a hierarchy of update functions on Elm. The major difference is that Elm Architecture is "fractal", that is, it usually describes hierarchical UI, and like React components, always nestable. In Redux, however, there is always a top-level "entry point" (store), and so some things inherently live on the top level (such as middleware). This makes it harder to reuse components coupled to Redux because they assume a specific top--level state shape, or a specific middleware. Elm Architecture also models complete UI, whereas Redux is typically used solely for the "model", and the role of UI is often given to React. The differences between React composition model and Redux also contribute to React/Redux being less cohesive as a whole than Elm Architecture. As for historical context, neither me nor Andrew fully understood Elm Architecture when we were working on Redux, and only realised the similarities post factum. Nevertheless we're happy to direct people interested in such patterns to Elm which is worked on by smarter people than us.

You can get pretty far without a state management solution like Redux, but for any non-trivial app, I wouldn't recommend it. But as I've said in a few responses already, I don't think it's wise to put everything into your Redux store.

The rule of thumb I follow is: when in doubt, implement your state using React component state (that doesn't mean you can't use a reducer). Only move it into Redux once it becomes necessary.

One of the most common pain points is complex asynchronous behaviour since Redux was designed for synchronous updates. I think redux-observable is amazing if you're into Rx. If you're not, redux-saga is a decent alternative. But don't go for them unless you actually have complex asynchronous code!

I'm only in my third week so I'm still in Bootcamp. (Bootcamp is Facebook's onboarding program for new engineers. It typically takes about 6-8 weeks, and it's used to both familiarize yourself with Facebook's product and engineering practices, and also to help you figure out what team you want to join.) Once I'm done with Bootcamp, I'll be joining the React team—which is exciting for many reasons, including that I'll be on the same team as Dan!

I doubt Redux will be be affected. However, one of the negative consequences of Redux's phenomenal success has been a trend away from using React's component state. There's a common misconception that using component state is bad or an anti-pattern because it's not as pure or functional as a Redux reducer. But not everything belongs in a global Redux store, and local component state is often the more appropriate place for many kinds of state in your app. I believe what people are really responding to is the awkwardness of the setState API, which has some edge cases and quirks that can be confusing. (See this Twitter thread for an example: twitter.com/acdlite/status/778268473772285952) The React team is interested in exploring ways to make the state API more functional and "Redux-y."

Dan and I weren't too familiar with Elm when we first started working on Redux. We had read the Elm Architecture document, but for whatever reason (perhaps our unfamiliarity with its ML syntax) neither of us really understood it. It was only later, after coming up with "reducers" and reducer composition independently, did we realize how similar Redux is to Elm.

The biggest difference is that the Elm Architecture is fractal. An Elm model's structure mirrors the structure of the UI, via composition. In other words, most Elm update functions (reducers, in Redux parlance) have a corresponding view.

Redux also uses reducer composition, but its composition does not mirror the composition of React components. In fact, we typically recommend that Redux reducers do not correspond directly to components. Those types of reducers are usually best implemented using local state.

I recommend learning Elm to pretty much every front-end developer. It's great that FP-style patterns in JavaScript have become more popular, and I'm absolutely thrilled that Redux has played a part in it, but there's only so much FP you can do in JS given the limitations of a language. Elm is an ML-style, purely functional language, so you'll get to learn things like pattern matching, algebraic types, and "immutability everywhere" that aren't possible with JavaScript.

Whether you learn Redux or Elm first probably varies from person to person. Dan and I both didn't really understand Elm until after we had created Redux and "accidentally" (subconsciously?) borrowed some of its ideas. We've heard from other people who report the same. So if learning Elm is overwhelming, give Redux a try and go back to Elm later to get the full experience.

Hi Chris! Please refer to the second part of my answer here: hashnode.com/ama/with-redux-cisteui6p005gzx53fstg…