The Easiest Way To Learn React? Learn Vue.

I struggled with fairly frequent “surprise” around the way React behaves for a while when I first started it. On the bright side, I had the good fortune of stumbling on and learning a similar framework, Vue, a few months ago. It’s the best kind of library: you can casually fix things without reading much documentation, and major refactoring operations are easy because of the straightforward and consistent syntax. Spending a month with it was the best thing I could have ever done to learn React. Let me explain. learning The React API surface is the topic of much debate — some saying it’s hard to understand (usually trying to be helpful), and iamverysmarts shouting them down. I think the fundamental problems of React are threefold: JSX is weird. That’s not to say it’s bad — you can make it do magical things, but it’s not a template language, and it’s not . Javascript State management is confusing: Data can be on , , or . There are no callbacks to inform you of changes to , but there are for and . is doesn’t set the state. this this.state this.props this state props this.setState Constant deprecations: the React team (bless their hearts) are always moving forward, but there are now so many very different ways of doing things, it’s hard to build a consistent, learnable codebase that withstands the tests of time. So let’s take a look at how Vue handles some core issues, and what we can learn about React from them. Templates Templates are converted to Render functions in a way that is easy for developers to understand. You may be able to replicate some of this behavior with a react-focused template package. For both React and Vue, there are cases where templates just aren’t that great, and then you can fall back on render functions and JSX. One Source of Truth In Vue, there is only one place where data can live — and that’s on the object itself. All data is on , from JS code, and in templates. It’s available from within templates, from other components, etc. You can’t have props have the same name as some state variable — it’s all under one namespace. It’s easy to shoot yourself in the foot with React, by having , , and maybe even a , all with important and distinct functions in your code. The least confusing way to use React is to minimize the number of places that state comes from, and make it clear how it works. If you have a prop and some internal state (say, the value of an editable field), make sure they’re named different things, so they don’t get mixed up in your head. this this.something {{something}} this.props.value this.state.value this.value State Queue In React, calling doesn’t immediately mutate . This is because, y’know, . Fine, but this is hard to reason about. The only way I’ve been able to make sense of it is to have a strict pathway of data. From or events to my own synchronous state hash (I usually call it ), and then actually calling from the function that mutates ( ). All logic only touches , and the render function only touches . This saves the confusion of having your state hash out-of-sync with the logic of your application. I have found it consistently impossible to get complex, asynchronous logic around state changes to be possible with the call, without the code devolving into a mess of mutexes, state variables etc. Best, in my humble opinion, to have a completely identical, duplicate, but synchronous source of truth somewhere that React doesn’t care about. setState this.state reasons really this.props this.syncState setState this.syncState setSyncState syncState this.state setState Deprecations There’s no way to beat around this bush — APIs change. Vue went from 1.0 and 2.0, with a huge amount of breaking changes, and the time around the switch was awkward. React seems to sprinkle big changes throughout. Good luck if you’re trying to upgrade past a few versions. The most important thing I learned from Vue was just what should be in a component, and how components should behave in relation to other components. React offers very similar core features compared to Vue. Vue just offers more guidelines & best practices. Building a few Vue apps gave me a much clearer idea of what belonged where, and when I went back to React, I knew exactly where things should go, and how they should be put together. I guess I’d say that if you’re starting a new app, give Vue a try, even if you really love React. If you’re waist-deep in a React app, and are struggling with structure, data flow, or component delineation… spend a week fooling around with Vue, if you’re like me, the wisdom you gain from the experience will more than make up for the time it took.