@acdlite
Front-end engineer at Facebook
Nothing here yet.
Nothing here yet.
No blogs yet.
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.
I knew Redux would be popular pretty much the moment I saw Dan's original version. I had a semi-popular (at the time) Flux library called Flummox, so it would have been easy for me to be stubborn and deny the obvious benefits of a reducer-based Flux. In one of my proudest moments, I instead quickly deprecated Flummox and jumped on the Redux train. Zero regrets. I caught some flak for this (reasonably—I could have done a better job transitioning Flummox users to Redux) but it ended up being a great decision, both for me personally and for the Redux community as a whole. So my open source advice is this: you are not competing against other libraries. Well, I mean, you are, but if you focus mostly on "beating" the other guys and gals, you're eventually going to fail. Work on finding the best solutions, regardless of whether that's by collaborating on someone else's project or starting your own.
I agree that the difference between a "dispatchable" (something you pass to the dispatch method) and a proper "action" (the actual object which is sent to the reducer) can be confusing. We struggled with the right terminology for distinguishing these concepts in the docs. We landed on "async actions" and "actions" but I've never been that happy with those terms. Observables are, indeed, a great abstraction for dealing with asynchronous control flow. Have you heard of Redux Observable? It seems to be exactly what you're looking for. Also, as I mentioned in a different response, "[the] reason the middleware API exists in the first place is because we explicitly did not want to prescribe a particular solution for async." My previous Flux library, Flummox, had what was essentially a promise middleware built in. It was convenient for some, but because it was built in, you couldn't change or opt-out of its behavior. With Redux, we knew that the community would come up with a multitude of better async solutions that whatever we could have built in ourselves.
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.
Agree with Dan! While I haven't personally used Redux Observable or Redux Saga in a large app, I think they're an amazing realization of the vision we had for middleware last summer. The reason the middleware API exists in the first place is because we explicitly did not want to prescribe a particular solution for async. Redux Thunk is promoted in the docs because it's the absolute bare minimum solution. We were confident that the community would come up with something different and/or better. We were right!
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.
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.