I am learning about React and I found a talk given by Pete Hunt as one of the best “birds eye view” introduction to React(even though it’s from 2013). There is enormous amount of tutorials on React. However, a lot of them only explain the HOW of React and don’t adequetly explain the WHY of React. I believe knowing the WHY in anything comes first / is much more valuable than the HOW.
Here are some notes I took from the talk:
- React renders your UI and responds to events.
- or simply put Function(data) = View
- Then the entire React application becomes a composition of functions and JSX is an abstraction over those functions.
1. Building components, not templates
a. What does separation of concerns mean?
- It means reducing Coupling and increasing Cohesion.
- Coupling: The degree to which each program module relies on each of the other modules. If you want to implement a feature of fix a bug and you make a change to one module or class, how often do you have to go to other parts of your module or codebase and make changes in order for that feature to work. These sort of cascading changes are symptoms of coupling and that’s what makes software hard to maintain.
- Cohesion: The degree to which elements of a module belong together. It is based on the single responsibility principle and basically means grouping related functionality into modules. The litmus test is to ask “does this function make sense?” or “Is this function doing a lot of stuff and can you refactor it into other pieces?”
b. A framework cannot know how to separate your concerns for you.
- It should only provide powerful, expressive tools for the user to do it correctly. This powerful and expressive tool is a React Component.
- React Component = A highly cohesive building block for UIs loosely coupled with other components.
- React Components are reusable, composable and unit testable.
2. Re-render the whole app on every update
- This is the key design decision that makes React awesome.
- Building UIs is hard because there is so much state. Lots of UI elements, Design iteration, crazy environments, mutable DOM, user input, etc.
- Data changing over time is the root of all evil. It is really hard to reason about.
- “Our intellectual powers are rather geared to master static relations and our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program(spread out in text space) and the process (spread out in time) as trivial as possible — Dijkstra
- In short, what Dijkstra is saying is that it is really hard for us to think of processes over time but it’s fairly straightforward for us to trace the flow of a program.
- So we should take processes that go over time and build abstractions that make them look like programs that execute in a single point of time.
- It was easier in the 90’s: when data changes just refresh the page.
- With React when the data changes, React re-renders the entire component. This makes it really easy for us to think about what state our application is in. That is, React components are basically just idempotent functions. They describe your UI at any point in time, just like a server-rendered app.
- Re-rendering on every change makes things simple. Every place data is displayed is guaranteed to be up-to-date without an explicit DOM operation — everything is declarative.
- However, re-rendering on every change is an expensive operation! And that’s why React also comes with a Virtual DOM.
3 Virtual DOM
- Makes re-rendering on every change fast.
- You can’t just throw out the DOM and rebuild it on each update.
- Virtual DOM is built to optimize for performance and memory footprint.
- On every update…React builds a new virtual DOM subtree…diffs it with the old one…computes the minimal set of DOM mutations and puts them in a queue…and batch executes all updates.