DEV Community

João Guilherme do Amaral Vequiato
João Guilherme do Amaral Vequiato

Posted on

You DON'T know Reactjs - Part I

A brief reflection

One thing that deeply bothers me these days are course sellers who promise easy jobs and exorbitant earnings, but whose content offered is so shallow and simplistic that they only teach people to be mere spectators of code - to look, copy, and paste. However, this is not always the instructors' fault.

In fact, there are several courses on the market that are excellent for getting a kick-start and allowing you to quickly position yourself in the job market - I myself achieved this through this method.

However, many aspiring developers (and some even with senior positions) are content to just consume these contents, replicate, make a to-do list, and that's it. They don't know what happens behind the scenes.

Not that understanding the intricacies behind everything is essential to work in the field, but it is certainly essential for you to stand out as a sought-after developer in the job market.

Some time ago, I helped two friends take tests for a first job who had done courses that promised that you would become full-stack in 4 weeks. It's scary to see that these courses make people complete 5 different projects and they leave the course without knowing the basics.

It's a huge false sense of learning, and the method is always the same: you see the guy coding a project x, do the same while watching and you're done. You have your first system, easy and simple as baking a cake.

Thinking about this, I decided to write this article to assist - those who want to get out of mediocrity - and to help Reactjs developers understand, at least a little, what React does behind the scenes.

Let's go?

Fundamental concepts of Reactjs

Can you tell me in a few words what React is today? - take a minute and try to answer in your own words.

I don't want to get into technical definitions here, so I'll use my own words too.

React is a library that allows you to write performant and easy-to-maintain code through the concept of reusable components, where you can describe user interfaces declaratively, without worrying about implementation details.

Is it difficult to understand? Let's try an easier definition:

React is a badass library for writing performant and easy-to-maintain declarative UIs.

Declarative programming vs imperative programming

But what would be a declarative way of writing a UI?

The declarative way is the way React works. Basically, you declare what you would like to happen in the user interface when a certain action is called.

Unlike the imperative way, which instead of describing, you have to command that it be done.

Let's use an example with React (in a declarative way) and the same example of how it would be in an imperative way.

Declarative way:

import { useState } from "react";

const MyApp = () => {
    const [isLoading, setIsLoading] = useState(false);

    const buttonClickHandler = () => {
        setIsLoading(true);
    }

    return (
        <button onClick={buttonClickHandler} disabled={isLoading}>
            {isLoading ? 'Loading...' : 'Click me'} 
        </buton>
    )
}
Enter fullscreen mode Exit fullscreen mode

In the example above, we declare that when the user clicks the button, the user interface should update the text to "loading" and disable it.

We don't have to worry about how it will do this, just show it which interface we want when a certain action occurs and it will figure out how to make it happen.

How would the same code look in an imperative way?

const button = document.createElement('button');

const buttonClickHandler = () => {
    button.disabled = true;
    button.textContent = 'Loading...';
}

button.addEventListener('click', buttonClickHandler);

document.body.appendChild(button);
Enter fullscreen mode Exit fullscreen mode

We need to worry about every detail we want when the user clicks the button, such as disabling it manually, changing its text manually, and even creating the button itself and inserting it into the DOM.

With our friend React, all of this logic is abstracted.

HTML and the DOM

In the end, everything we do in React serves a single purpose: rendering HTML elements in the DOM (Document Object Model).

What is the DOM?

The DOM is a hierarchical tree representing HTML elements, used by web browsers.

In simpler terms, it's everything the user sees on the browser screen.

It's the <p>, <h1>, <div>, and <button> tags and their respective children that you put on your webpage.

When you write an HTML page (or your React components, which will ultimately also be an HTML page), this is how your browser interprets each element.

Document Object Model

This is the DOM.

But why React?

Javascript is the easiest and most common way to manipulate the DOM, whether to add or remove elements, add or remove attributes, add interactivity, among others.

However, directly interacting with the DOM and "painting" these interactions on the screen is very expensive, which can bring a poor experience and many performance problems.

React - in addition to making our lives easier with the form of declarative programming and the possibility of reusing components - has a very intelligent algorithm of reconciliation allied with its Virtual DOM, which can make this process much more performative by making the minimum possible changes directly in the user's DOM.

But that's a topic for part II of this article series (if it exists).

Comment below what you thought of this content, if you liked the way it was written and if you want me to keep writing about it.

See ya! 👋

Did you like it? Check out other articles written by me:

Maximize your learning and productivity with this Chrome extension
React Render Props Pattern
6 React questions for technical interviews and their answers
Understanding closures
Understanding classes and prototypes
Understanding Higher Order Function

Top comments (0)