3 fundamental things I learned about React
Tags: beginners, javascript, webdev, react
Published: 2017-08-10 13:17:22

---
title: 3 fundamental things I learned about React
published: true
description: why use React?
tags: beginners, javascript, webdev, react
cover_image: http://i.imgur.com/J1Oioug.png
---
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](https://www.youtube.com/watch?v=x7cQ3mrcKaY&t=11s)(even though it’s from 2013). The talk helped me really conceptualize why I was actually using React while making [my first React app](http://www.tamrat.co/zaha-a-visual-note-taking-app/) :)

There is an enormous amount of tutorials on React. However, a lot of them only explain the HOW of React and don’t adequately explain the WHY of React. I believe knowing the WHY in anything comes first and over time, becomes much more valuable than the HOW.

Here are some notes I took from the talk:

##Short version

1. Build Components, not templates.

2. Re-render, don’tÂ mutate.

3. Virtual DOM is simple andÂ fast.

##React

* React is a JavaScript library for creating user interfaces.
* React renders your UI and responds to events.
* Simply put React's basic formula is **function(data) = View**
* A JavaScript function accepts arguments and returns a value. Similarly, a React Component receives data (props) as an argument and returns a UI(view). 
* Then the entire React application becomes **a composition of functions** that together makeup the object representation of your UI(View).
* JSX is just an abstraction over those functions and it simply transpiles down to a JavaScript representation of a DOM object.

##1. Building components, not templates

###a. What does separation of concernsÂ actually mean?
* Separation of concerns doesn't mean separating technologies (i.e. templates). It means **reducing Coupling and increasing Cohesion** between the concerns regardless of technology.
* **Coupling**: The degree to which each program module relies on each of the other modules. If you want to implement a feature or 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 and 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 uses components to separate our concerns with the full power of JavaScript and not crippled with a templating language.
* 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, Dijkstra is saying 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.
* Now 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 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

* 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 when performing a re-rendering.
* On every update, React builds a new virtual DOM subtree and diffs it with the old one. Then it computes the minimal set of DOM mutations and puts them in a queue and finally batch executes all updates.

---