React In Theory

Jerome Olvera
Yellowme
Published in
4 min readJul 9, 2020

--

Some time ago, reading on Twitter, when Vue was starting to gain popularity the community asked Dan Abramov, the React Guru since React 16, if he thought that at some point React as a library would be replaced by any other alternative, pointing at the time to something like Vue. He replied that it was somewhat probable that in the future something might replace React as a library but he was confident that the React model would prevail for much longer.

Photo by Jason Leung

What is the React “Model”?

The explanation shown here is based on a “Formalized” description in the React repository called “react-basic”. They also explain that it is an attempt to have a mental model of how the internal mechanism “works”, but that in practice, like everything, it is somewhat more complex.

Transformation

The core premise for React is that UIs are simply a projection of data into a different form of data. The same input gives the same output. A simple pure function.

I have read the previous statement from many authors like Erick Eliot and the React Team Core itself, we write functions all the time when we develop software, functions that transform their arguments input into a “derivation”.

In React we write:

function Greeting({ name }) {
return (
<p>{`Hello, ${name}`}</p>
)
}

And this is perfectly the same as:

function greeting(name) {
return `Hello, ${name}`
}

React keeps the essence of programming in Javascript alone.

Abstraction

All software problems are solved with Indirection. Indirection is the ability to refer data by another name. And the application of this technique in React is very transparent.

Again with the previous example, the function (component) `Greeting` allows us to refer to it without having to think that it’s in fact a DOM element, we know by its name and arguments that it will present a greeting to the name passed as an argument.

Composition

Composition is the essence of programming, taking a problem and breaking it down into smaller parts, then building a complete solution by combining small solutions.

In my first high school programming class, I was told that software development is “the act of breaking a complex problem down into smaller problems, and composing simple solutions to form a complete solution to the complex problem.” — Erick Eliot

Having this same ability and just changing the word “Compose Functions” to “Compose Components” enables us to develop complex interfaces from small reusable UI elements.

function Header() {
// we assume that we have a function
// from which we get a user
// in our application
const user = useUser();

// without having to modify the behavior
// of Greeting we can use the same element
// in different parts of our application
return (
<div>
<Greeting name={user.name} />
<nav>
<a href="/profile">Perfil</a>
</nav>
</div>
)
}

State

When I look at other libraries that are inspired by React, I take time to review what is their “proposal ” to handle the state of the application.

UIs could be just projections of the data sent from the server to the clients, but there is an intermediary that we cannot control and it is the User. The "state" is the combination of the data in our application and the interactions of the user.

The model that React proposes consist of atomic transformations of user interactions, which allow us to take the user along a path defined by the developer, built by declarations (functions) that update the state of our application in a predictable way.

Among other technical advantages, we have the ability to "time travel" knowing the state of the application at a certain point, some of this patterns are strongly implemented in libraries like Redux or the State Reducer Pattern.

A single function that is responsible for combining user interactions and out application data:

function countReducer(state, action) {
switch (action.type) {
case "increment": {
return { count: state.count + 1 };
}
case "decrement": {
return { count: state.count - 1 };
}
default: {
throw new Error(`Unhandled action type: ${action.type}`);
}
}
}

We can describe user interactions that implement the possible state transformations:

function increment() {
dispatch({type: 'increment'})
}

And always be sure of the behavior of the behavior of user interactions:

function CountDisplay() {
const [state, dispatch] = React.useReducer(countReducer, {
count: 0
})
function increment() {
dispatch({type: 'increment'})
}
return (
<div>
{state.count}
<button onClick={increment}>
Increment
</button>
</div>
)
}

Beyond JavaScript

In my path of learning new technologies I've been able to take a look at how libraries like SwiftUI and Flutter work. In my opinion, they make a good match for the React model. I have not read any “formal” definition of them, like the one that the React team presents in react-basics. I can play around those libraries without any limitation, bringing my previous knowledge between them and learn new good practices from other ecosystems. I feel more motivated to learn how to develop native applications in iOS and hoping that Android with its Jetpack Compose brings me the same feel.

Some external links that I use as an inspiration and reference:

Entrevista a Guillermo Rauch, CEO de Vercel (SPANISH)

--

--

Jerome Olvera
Yellowme

Staff Software Engineer en GBM Grupo Bursátil Mexicano