Design Principles – React

I’d never read this before. It‘s a document from the React team stating, essentially, the philosophical underpinnings of why the build software they way they do.

One of the things I found interesting was their perspective on setState() and why it’s asynchronous. After all the things that’ve been said about setState() their articulation about how they think about it is probably the most helpful I’ve heard and what we should teach to beginners: that it’s not so much about “setting state” as it is “scheduling an update”. of what setState() a

There is an internal joke in the team that React should have been called “Schedule” because React does not want to be fully “reactive”.

One of the real powers I think behind React is the ability you have as a developer to trace as state of the UI to the data that produced it. This explicit design goal really does “turn debugging from guesswork into a boring but finite procedure”:

If you see something wrong on the screen, you can open React DevTools, find the component responsible for rendering, and then see if the props and state are correct. If they are, you know that the problem is in the component’s render() function, or some function that is called by render(). The problem is isolated.

If the state is wrong, you know that the problem is caused by one of the setState() calls in this file. This, too, is relatively simple to locate and fix because usually there are only a few setState() calls in a single file.

If the props are wrong, you can traverse the tree up in the inspector, looking for the component that first “poisoned the well” by passing bad props down.

This ability to trace any UI to the data that produced it in the form of current props and state is very important to React. It is an explicit design goal that state is not “trapped” in closures and combinators, and is available to React directly.

While the UI is dynamic, we believe that synchronous render() functions of props and state turn debugging from guesswork into a boring but finite procedure.

I also liked the section where they talked about their own internal style of developing the React codebase and how practicality generally trumps elegance:

Verbose code that is easy to move around, change and remove is preferred to elegant code that is prematurely abstracted and hard to change.