Forays into react
Tags: react, frontend, javascript
Published: 2021-01-20 14:27:02

---
title: Forays into react
published: true
description: lessons learnt from react after a few months
tags: react,frontend,javascript,
cover_image: https://upload.wikimedia.org/wikipedia/commons/thumb/a/a7/React-icon.svg/1200px-React-icon.svg.png
---

Over the past few weeks, I have had to work with react for the first time in a professional capacity. Having gone through the usual 1) just start coding 2) ok this doesn’t work 3) let me actually read some documents process on every new feature, I have finally arrived at a relatively comfortable place with the framework. What follows is my high level understanding of the react framework. This blog is a conceptual overview of the react framework and the focus on react syntax is minimal. 

React uses component driven development. In traditional web development, you think about your app in pages. In react however, the [atom]( https://atomicdesign.bradfrost.com/chapter-2/) (building block) of your app is components. Each component is an isolated independent and reusable piece of the application. The components render separately and have their own lifecycle. This dance of when a component re-renders and what happens on that render is the fundamental theorem of react. 

#Component Hierarchy: 

The first challenge of any component driven development framework, react being one of many, is to identify said components. The challenge here, and for good programming design in general, is to make these components independent and isolated and by extension reusable. One technique for components, just like object or functions, is to make these components have one and only one responsibility. Take the below user interface for example:

![example](https://miro.medium.com/max/1000/1*VTKsiByHMcWDIxpFawp4fg.png)

There are at least five components here : 

1. TO-DO screen Component: The app. Its job is to be an umbrella for what all the other components are going to do. Useless but necessary, like a product manager. 
2. Header component : The TO-DO list heading. 
3. Input bar component: The add new task piece of the UI. 
4. Listing component: The bigger box of listings under. The listing component is to the TO-DO list items, what the TO-DO screen component is to the entire app. 
5. List row component: Each individual TO-DO item. 

The hierarchy would then be : 
- TO-DO screen
	- Header 
	- Input bar
	- Listing
		- List row 

For this simple TO-DO above, this may seem like over modularizing and that’s because it is. However, as the application grows, you start reaping the benefits of the design. Immediately for example, your second screen will be able to use the same header component and give your app a consistent feel. If you decide to categorize the listings (into work, school, home) for example, you only need to find the right wrapper for the existing listing components. 

##Rendering: 

In order for the UI to display your components, they need to render. The react magic is the React Dom. React DOM sits between your code and the browse DOM. The browser DOM is what is actually rendered onto the page and displayed to the user.  Components are react objects and importantly cheap to create. React Dom takes these objects and updates the browser DOM for you. There are two advantages to this. Firstly, your browser DOM is updated efficiently. React takes care to ensure that the browser DOM is updated as necessary and only if necessary. Secondly, you get to use the power of javascript and react libraries. The react DOM can render a lot more than the browser DOM. Importantly, React, allows the intermingling of rendering logic with UI logic. For example, when a user adds an item in the input bar component, the same react element that handles how the input bar is displayed, will also handle what happens when the add button is clicked. 

##JSX

JSX places the mark up (HTML) language inside the javascript. JSX is not required by react, however, it allows you to literally put the rendering logic (mark up) and UI logic (javascript) in one place. The isolation then moves from mark up and UI logic (separate HTML and JS files) to components. In your component, in one place, you can develop and see everything that is going with the header tag below. 

```
function formatName(user) {
  return user.firstName + ' ' + user.lastName;
}
getGreeting(user) {
  if (user) {
    return <h1>Hello, {formatName(user)}!</h1>;  }
  return <h1>Hello, Stranger.</h1>;}
```
##Props

Secondly, react allows you to pass props (arguments) from one component to another. For example, if we wanted to limit our list to 5 items, we could set this as a variable in the TO-DO screen component. The TO-DO screen could then pass this prop to the input bar and listing to ensure that the former does not accept more than 5 inputs or the latter does not display more than 5. Props are passed from a parent component such as listing to its child, the list row. A component will have access to the prop during its life. Unfortunately, components don’t live too long, forgetting all about what you just told them as soon as literally anything happens.

#Lifecycle: 

Because the react DOM is cheap to create, react elements are immutable. That is, you can’t update your react elements. The only way to make changes, is to re-render the entire element. Importantly, react does not do this on the browser DOM. React will only render what needs to be changed on the browser DOM! Working with the react DOM, you gets the benefit of thinking in isolated, cheap and always recycling components, all the while maintaining a high level of efficiency on the browser DOM. UI elements are always changing. The very first letter the user types in the input bar, changes the UI of the input bar. Subsequently, the UI of the TO-DO screen has now also changed. Once the user clicks ADD, all components in the component hierarchy above will change.  Each component here has a life cycle. Each cycle in the life of component, is one unchangeable react element with its own props. All the different forms a react component takes, forms its life cycle. Once a react component is mounted (rendered to the browser DOM), it is out of your control. However, before it's reincarnation, you get to play God using hooks. Traditionally, this intervention was done using states and lifecycle methods. More recently, in a functional turn, state hooks and effect hooks and other hooks are used to accomplish the same goals. 
 
##State Hooks: 

React component (read javascript functions) work with two groups of variables, dynamic and static. Static variables stay the same throughout all the reincarnations of the component. For example, one could define a variable as: 
```
 Header = <h1> TO-DO LIST </h1>
```
 On every render, the header will stay the same. States on the other hand, are what defines each render of the component. For example, all the list rows in our TO-DO list, have the same styling and look. What changes for each row, is the text. For example, the first row is our TO-DO listing row example component has a state of : 
```
 State =  {text: Vanilla Javascript, checked: True}
 
While the last one is:

 State =  {text: Node.js , checked: False}
```

Consequently, any time the state of a component changes, it will be re-rendered. Unfortunately, the component is destroyed completely on this re-render and does not remember its state. This remembering then must be done somewhere outside the component. One option is to update the state of the parent component, which not being destroyed, will remember the state and pass it back to the component as a prop once it is ready to be mounted again. Another option is to use a storage. A storage, which may itself be a component, will remember the state for all other components and will be used to store/retrieve the states. States are updated via the useState hook. 

##Effect Hook: 

Where states are the variables in a component, effects are the methods. An effect hook runs every time the component renders. Some effects do not return anything. For example, you may want to update the local storage. If you want to keep track of the number of tasks in the listing container, you can set up an effect on each listing row. Once added to the browser DOM, the row will update the number of tasks in the local storage using the hook. The row itself is unchanged, the new number may trigger a state change and re-render somewhere else in your react DOM. Another examples of these effects are calls to external APIs. Other hook effects are used to perform a specific action on the deletion of the component. These effect hooks return the relevant functionality. For example, your ToDo list item maybe synced with google calendar. You can then use an effect hook to call the calendar API to remove the corresponding event once your entry is deleted.

There are other hooks that can help manage the lifecycle of a component. State and Effect hooks can handle most of the cases for a react application. In a nutshell, you create a component with specified states and effects. On a state change, the component renders again relying on the local storage or its parent to remember the state change. Once the component has been rendered to the browser, your effects take place. These effects may themselves cause your component to render again or wait around for a render to be triggered before taking effect. On and on, the react components are created and deleted but never updated.