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 learning 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.

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:

1. 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.
2. State management is confusing: Data can be on this, this.state, or this.props. There are no callbacks to inform you of changes to this, but there are for state and props. this.setState is doesn’t set the state.
3. 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 this, this.something from JS code, and {{something}} 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 this.props.value, this.state.value, and maybe even a this.value, 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.

State Queue

In React, calling setState doesn’t immediately mutate this.state. This is because, y’know, reasons. Fine, but this is really 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 this.props or events to my own synchronous state hash (I usually call it this.syncState), and then actually calling setState from the function that mutates this.syncState (setSyncState). All logic only touches syncState, and the render function only touches this.state. 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 setState 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.

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.