DEV Community: Harry

How React reacts: understanding the flow of React

Harry — Fri, 22 Jul 2022 15:19:44 +0000

An overview

React is the most widely used library in web development and many new developers start learning react everyday. In this article we'll go through some topics that a react developer should know, and learn about the flow of react.

What is React?

React is a JavaScript library that is used to create user interfaces. React is the most popular front-end library to build user interfaces today. It allows us to easily write more efficient and better quality code to create user interfaces using a declarative programming style.

What is declarative programming?

When it comes to programming, a language can follow one of the two programming styles, declarative or imperative.

In Imperative Programming, we define the entire control flow for the compiler including the exact steps that it should follow to get what we want as the end result. We follow this style in Vanilla JavaScript, jQuery, etc.
In Declarative Programming, we only tell the compiler what we want as the end result, it is upon the compiler to decide its control flow and the steps it should take to get to the end result. We flow this style in React as in React we only define what the user interface should look like and not the control flow for the compiler to follow to make the user interface look like that.

Example:

Let's consider a classic Bruce Wayne and his infamous Alfred the Butler example to understand these programming styles in a more comprehensive way. Bruce Wayne is the programmer, and Alfred is the compiler. Here Bruce Wayne is hungry and he wants a Pizza with pineapple toppings.

In declarative style:

Bruce Wayne: I want a Pizza with pineapple toppings
Alfred: ready with a Pizza with pineapple toppings.

In imperative style:

Bruce Wayne:
Go to the kitchen.
Open a shelve.
Get some all-purpose flour.
Get some water.
Get some yeast.
.....
Alfred: ready with a Pizza with pineapple toppings.

Components

In react, the global user interface is made up of several smaller user interfaces, known as components. Components are the independent building blocks of user interface in react, and the reason we follow component-based approach in react is for better manageability and reusability of code. For example, suppose your building a web app which has 5 different pages, the content on each pages would be completely different but all the pages may have some common components, for example, a navbar. We could opt for either one of the two approaches here, we could either write code for a navbar and copy-paste it on every page and have a navbar on all our pages. This would surely not harm anyone, and it is also the second more recommended approach of the two approaches we have. But it is still recommended to follow the component based approach. Why? Because we follow something known as the Don't Repeat Yourself, or DRY, approach in programming. In the example above, we wouldn't only have just written the same code five times over, but also if we need to make some changes in navbar, we would have to make changes in all of the pages. Yes, we would have to make the same changes at five different places. In the second approach, we could create a navbar component and put it in all our pages, and whenever we need to make any change in navbar, we do it in the main component code block and it is reflected in all our pages. Sounds so much better and so much less hectic, right?

States and Props

All components in a React app have two things that defines how they look, states and props.

State

State is a built-in React object. Every component in React has a global state which is a representation of the component's current state, or data. A component consists of multiple states representing different set of data. For example, suppose we are building an app in which there is a button component, that button is used to toggle an action, and depending on whether the toggle is on or off, the color of the button changes. Toggle is basically a state of this component that decides what the button would look like. This toggle state would be available as a property in the global state of this component.

State can be modified because they originate from within the component itself.

Props

Props is short for properties. You may think of them as arguments and components as functions. Props are the data that an upper level component has and it is passed to a lower level component because the lower level component needs it to render in the defined way.

Props are read only. If you want a child component to be able to modify a prop, you would also have to pass a function, with the ability to modify the prop, from the parent component to the child component.
Props can only be passed from a component of upper hierarchy to lower hierarchy. By hierarchy here, I mean the level they are at in the DOM Tree.

JSX

Components in react are built using JavaScript XML, or JSX. JSX is a syntactic sugar and it allows us to write code that resemble HTML in react. We write code in react using JSX like this.

    <div>
      <p>This is para text</p>
    </div>

Element

Elements in react are plain object representation of components or DOM nodes. Elements are immutable in react and once created they can't be modified.
The JSX we wrote above would return an element which would look like this.


  type: "div";
  key: null;
  ref: null;
  props: 
      children: 
          type: "p";
          key: null;
          ref: null;
          props: 
              children: "This is para text";

Virtual DOM and Reconciliation

Virtual DOM, or VDOM, is a virtual representation of the Actual DOM, or DOM, which is stored in react's memory and is synced with the DOM using a library like ReactDOM. DOM is handled by browsers whereas VDOM is handler by frameworks and libraries like React, Vue, Elm etc. Both VDOM and DOM are generally represented in a tree-like structure which you have probably seen many times already.

Why VDOM when we have DOM?

Most common answer that you would find to this question is because VDOM is faster than the DOM, which is not entirely true. VDOM and DOM are two different technologies which handle different use cases. DOM is directly responsible for what you see on the screen, VDOM is not. VDOM is merely an object representation of DOM. When there is a change made in a react app, react reflects the change on the VDOM which is then compared to an earlier frame of the newly created VDOM using an algorithm called diffing, this algorithm let react know exactly what node in the VDOM has changed. React then proceed to change only those nodes in DOM which were affected by the change and doesn't unnecessarily re-render the entire DOM. You see, VDOM itself uses DOM is make changes in the UI, VDOM is not DOM 2.0. In fact, VDOM can actually be considered more expensive because of diffing and creation of a new VDOM every time something is changed. But VDOM is still used because there is no way for us to know in advance what nodes would be changed and in what way, and without being aware of this, our only resort would to be re-create the entire DOM every time something has changed, which is very expensive. This entire process of react registering a change, creating a new VDOM, comparing it with an older version of VDOM, figuring out the nodes it has to replace with newer ones, and then making those changes on the DOM is called Reconciliation. Reconciliation happens every time the render function is called, and the render function is called every time a change is registered in a react app.

Conclusion

We have reached the end going through almost all the topics that a beginner should know. I would personally recommend learning more about diffing if possible to have a better understanding on what counts as a change in react. I would love to hear feedbacks on this.

Byte Story: What happens when you type google.com

Harry — Wed, 20 Jul 2022 17:13:10 +0000

What is this about? An overview.

Applications like browsers make it look seamlessly easy to navigate through the web and load websites within seconds with nothing more than a couple of clicks or taps. However, in this article, we will be looking at the web not as the homo sapiens we are, but as the bytes of data that travel hence and forth with those clicks and taps. We'll see what happens between the instance you make a request on your browser to browse a website of your liking, and the instance you are served with it.

Aren't you a decade late for this topic?

Yes, I do realize that this topic is a bit too outdated for the time, but the primary reason why I chose this topic was to better understand how web works myself and if you're a newbie to the web ecosystem, I hope this article helps you understand some things better.

Getting started

Before moving forward, it's important that we set the context up. The website that we would be browsing to is goog.com, and we'll be assuming this is our first time to google.com on a brand new machine.

Starting our journey

Step 1:

You start typing google.com on your keyboard. The instant you type "g", the browser will search through its history and start suggesting you all the queries or websites that you have gone through in the past that contain the word "g". If the browser fails to find anything in the history, it would go one step further and send a request to the search engine server and come back with some queries related to the word you have typed. This behavior may vary from browser to browser.

Step 2:

Now that you've typed google.com and hit enter, the browser has to figure out whether the typed query is a search query or an URL. The browser does this by checking whether there is a top-level domain attached to the query or not. In our case, it has a top-level domain attached to it and so the browser takes it as an URL and moves forward with it.

Step 3:

Now that the browser has got an URL, it attempts to create a connection with the server, but before that, the browser has to figure out the protocol that the requested URL uses to communicate. That's where HSTS comes into picture. HSTS stands for HTTP Strict Transport Security and it is basically a list that the browser has. The list contains all the domains that can only be accessed on a HTTPS protocol. google.com uses HTTPS, so the browser will move forward using HTTPS.

Step 4:

Now we've got everything... almost everything, to establish a connection with google.com server. But, we can't initiate a request to establish a connection without knowing where to send the request. google.com is just a domain name and not a literal address. When I say address, I don't mean address like 221B Baker Street, London NW1 6XE. The term address here refers to IP addresses. At it's core, the concept of IP address is very much alike to that of our home address. The browser already knows the domain name to which it has to send the request, now it has to find the IP address of that domain. Generally, the browser would have looked up the cache memory of its own, the OS, router and ISP, in the respective order, to check if it has the IP address of the requested domain name stored there, but since we haven't ever been to google.com, the browser would fail to find anything in the cache. This is where we introduce the nightmare of networking, Domain Name System, or simply, DNS. Consider DNS as a mapping of domain names and their respective IP addresses. You may think of it as your phone contact list, where you save the phone number of someone and then look it up using the name you saved it with. Now replace phone numbers with IP addresses and contact names with domain names, and you have a basic and naive representation of what DNS is. The process of establishing a connection with a DNS server and doing a DNS lookup is very long and complex, and so I won't be going into its details in this article. The browser would now do a DNS lookup and find the IP address for google.com and move forward with it.

Step 5:

Now, the browser is required to establish a connection with google.com using an internet protocol. There are several internet protocols out there but Transmission Control Protocol, or TCP, is the most common of them. The browser would now initiate a TCP connection between the IP address of client and google.com' IP address over HTTPS protocol. Once the TCP connection request reaches google.com, and if everything goes right, google.com responds with a similar request and a TCP connection is then established. There is more to establishing a TCP connection than this but this is briefly what happens when establishing a TCP request.

Step 6:

Finally, we have established a connection with the IP address of google.com, and now we are ready to exchange data, exchange data as TCP connection is a bi-directional connection and it can be used to both send and receive data. A long and tiring journey it was. But before we exchange any byte of data, we need to establish a Transport Layer Security, or TLS, connection and introduce the concept of encryption. TLS connection is important because it helps to secure the data that would be exchanged from outside vulnerabilities. When a TLS connection is established, both client and the server end up having a symmetric key which they use to encrypt and decrypt data.

Step 7.

Now we can start sending requests to google.com. The first request that our browser would send is generally a GET request, unless you are sending some data, like credentials, with your request. Our request will have a header containing some information about the request, like what types of request would it accept in response, a connection header that will tell the server to keep the TCP connection alive for further communication, cookies (if there were any), and etc. Once the request reaches the server, it passes the request through a request handler and reads what it asked of it and generates a response accordingly. The response would somewhat share the same body as that of the request we sent earlier but would include additional information, like response status details, and is probably going to include cookies as well.

Step 8.

In this final step, depending on the content type of response, the browser would act parse the response accordingly. Since we are going to google.com, the response would include the data that would be used to build the google.com homepage.

Conclusion

We've finally reached at our destination, homepage of google.com, with maybe a better understanding of the how.
This is one of my first technical articles related to web development and I would love to hear any feedback on this.