Spelunking in the React ecosystem
Much has been written about React’s steep learning curve. To some extent the challenge is that React and Flux/Redux turn MVC orthodoxy on its head. However, I think the greater part of the difficulty stems from the fact that “React” is shorthand for dozens of libraries and tools needed to make a real-world app.
Developers who have been immersed in React-world for a while may not realize just how much tribal knowledge they’ve picked up along the way and assume that everyone knows. Project READMEs and examples often have little more than “this library is like X, except a little different.” Learning React can feel sometimes like an endless yak-shaving expedition.
Even if you are fully up to speed on webpack, nodejs, express, es6, babel, mocha, sass/less, etc., building a non-trivial app in React will likely require a dozen or more React-specific libraries and tools. Each is relatively simple on its own, but composing them into a real app is not.
I should say that I am all for the trend away from large frameworks toward small, composable libraries. I like that the React ecosystem is a bunch of small libraries.
The paradox of choice
That said, the React ecosystem is still young, and is changing fast. There are dozens, if not hundreds, of small libraries to discover and learn. Given any specific problem to solve, you can find two, five or twenty libraries that solve it in different ways. And most of them are changing all the time. Version incompatibilities are everywhere.
Choices are nice, but the paradox of choice is a heavy burden when you’re staring at an empty `project.json` file.
Starter kits have emerged to help you, um, get started more quickly. The well-executed ones require little more than:
git clone
npm install
npm start
But even with those helping hands, the paradox of choice remains: there are so many starter kits that there is also a React starter kit search tool. As of this writing (July 2016), it contains 94 entries.
Magic and understanding
I love a good template, just like I love a good IDE or command line tool that seems to magically do everything for me. But I am not the type of person who is comfortable with magic once I’m out of the beginner stage.
I want to know exactly what my tools are doing for me. If I don’t, I won’t know when a tool is no longer appropriate for my situation or when I am using it in a potentially dangerous way. I won’t be able to make good tradeoffs between performance and convenience, or between writing/testing/maintaining custom code and taking a dependency on something I don’t control.
“When you type foo.com into a browser, what happens? Then what happens? Then what happens?” I ask this question not because I care how deep you can go; I ask because I care how deep you care to go. Where does your interest stop? How do you THINK it works? Where does technology end and where does the magic (for you) begin? HTTP? TCP? DNS? Voltage on a wire? Registers in chips? Quantum effects?
— Scott Hanselman
So we have dozens of excellent tutorials on getting started with React. And we have some excellent starter kits that each pre-package one possible set of compatible React-related libraries. But someone else has determined which libraries are included.
What I haven’t found is a guide to help developers — especially those new to React like I am — make their own decisions about which libraries to take dependencies on.
If you know you want redux, redux-thunk, react-router, and redux-form, the Starter Kit search will help you find a starter kit that includes them.
But what if you have questions like:
- How does redux-thunk work, and why would I choose it over redux-promise, redux-async, redux-await, redux-async-connect, react-fetcher, or react-resolver? Or do I use it in combination with one of those?
- Can I use react-bootstrap and redux-form together? In which versions?
- Should I use flux-standard-action, redux-actions, redux-standard-actions, or none of the above?
- When I have a problem that I know has been solved before, how do I discover the currently popular options and not spend time figuring out which have been abandoned?
These are the types of questions I plan to discuss as I walk through my learning over the past couple months. Of course, I can’t decide what’s best in your situation. But I will try to explain the magic tricks, discuss the tradeoffs you may need to consider, and warn about the current pain points and incompatibilities.
Let me repeat: I am a React beginner. I’ll likely say something just plain wrong. I’ll change my mind. I’ll misunderstand a concept or the purpose of a library. That’s life as a developer.
I welcome your thoughts and look forward to learning from you!