DEV Community: MirAli Mobasheri

Tailwind in Reality: Bringing CSS Classes to Life with AI Videos!

MirAli Mobasheri — Tue, 22 Jul 2025 15:47:39 +0000

Hey folks! 👋

I just dropped a mini-series on YouTube called “Tailwind in Reality”, where I used ChatGPT's Sora AI to turn four Tailwind CSS classes into real-world magic.

For example: rounded-full → a square pizza becomes a perfect circle

Imagine a world where every action, every shape, and every motion is driven by a Tailwind CSS class—buttons float, objects morph, and interfaces blur into reality. 🌀

Check it out below and let me know which transformation blew your mind! 🚀

How It Was Made

Videos: Sora AI (ChatGPT Plus, 20$ subscription)
Voiceovers: ChatGPT Advanced Voice Mode
Music: SunoAI
SFX: Transitions & ambient from freesound.org

I’ve just launched my channel, MirAli Makes, to explore more AI experiments, dev tutorials, and creative projects. I’d love your feedback—what Tailwind class should come to life next? Drop your ideas below! 🎨✨

JavaScript: The Klassic Way!

MirAli Mobasheri — Sun, 21 Jan 2024 06:57:33 +0000

Before there was the class keyword, there was the constructor function. And now that there are classes, the constructors are still there. Indeed the classes are only a syntactic sugar for what constructor functions have been doing for a long time.

This post is about the Klassic JS, an era before the class keyword existed. When developers used constructor functions to implement Object-Oriented Behavior. But this doesn't mean it's useless. All the things we learn about, in this article, are actually how JS still works under the hood.

We'll start by reviewing how special data types likes Functions and Objects are treated in JS. Then we'll progress through creating objects using Constructor Functions. And in the end, we'll learn how JS implements some advanced OOP patterns.

1. Functions And Objects

When learning about JS' OOP, objects are the things we'll be talking about. But functions are the ones we'll be using to build those things.

Let's have a quick look at how these two relate in JS.

1.1 Everyone Is A First-Class Citizen

Suppose you've a string variable named a.

let a = 'Hello World!';

You can check how many characters it has using its length property.

console.log(a.length) // 12

Now let's suppose you've an array, named b. You can still check how many elements it has using the same property, length.

let b = ['Hello World!']
console.log(b.length) // 1
console.log(b[0].length) // 12

What if we define a function and try to log its length? Does it still work? Let's test it with an add function.

const add = function(a, b) {
  return a + b;
}
console.log(add.length) // 2

The log command in the above code block, will output 2. It's how many arguments the function takes (a and b). This means that the function we defined has its own set of properties and methods. Like any other of the value types we checked.

This is a simple explanation of what Functions As First-Class Citizens in JS means:

Functions in JS aren't treated like some subroutine to be called later. They're stored as an object. We can store them into variables, pass as arguments and return from function calls.

But, what we're most interested in, is how we can use them as Object Constructors.

1.2 So Everything Is An Object?

Well, not everything. As a matter of the fact, the string variable, we defined (a), is known as a primitive value. So, it's an exact value stored somewhere in memory and assigned to a variable's memory address.

But how does a.length work, if it's a simple value rather than an object?

Any time you try to access a property or a method on a primitive value, JS will provide an Object Wrapper for the value. It uses that wrapper to give you access to the methods and properties.

So, while everything is not an Object, many things are treated as one. This means objects are a core part of JS. That makes them important when interacting with the language's API.

2. Constructing Objects

In most Object-Oriented programming languages, blueprint is a keyword in explaining OOP structures. But this isn't the case for JS.

In JavaScript, the keyword is prototyping. This is how the language, shapes the objects's structure and behavior. There's a prototypal inheritance chain in the background. It specifies what properties and methods are accessible by an Object Instance. This simplifies the process of sharing properties among different instances of an object.

We create these instances using constructor functions. So, before we get deep with the prototypes, let's see what a constructor is and how it works.

2.1. Functions Will Do The Job

Constructors are functions. You can define a function. Call it with a new keyword, and congratulations! You've used a constructor.

But in order for a constructor to be a useful one, you should write a useful function. How's that? Let's look at some examples.

Do you remember the add function? Let's recall the code block:

const add = function(a, b) {
  return a + b;
}

This function simply takes two numbers and returns a new one. We can call it with a new keyword, if we want to.

const adder = new add(1, 2)

But this line has no meaning. The adder is an empty Object. Of course not an entirely empty object. We'll get to that later. But in our case, this line is meaningless. In order to write a useful constructor function, we need to use the this keyword.

By using this we can access the instance of the new object that is created when the function is called with the new keyword.

But first let's check what an instance is.

2.2 I have an instance, therefore I exist!

We're all Humans.

Indeed, human is a species name. We all share some traits which differentiate us from other species and animals. We can walk on two legs, we have two eyes, and we can speak in different languages.

While all of us are humans, we're not the same human. Each of us are unique. Our birthday is different. Our parents are different. We're born in different locations, and we even have different names.

The difference is what we can call the identity. You might be of the same type as the others, but you've got a different identity.

The constructor functions, will produce new Objects. These objects will share some traits, but they're not the same production. Each of them is located in a different memory address from the others.

So each instance of an object, is a working example of that object that is stored in a specific memory address.

Now we can finally try creating an object with a constructor function. And see where it goes.

2.3 `new`

We already learned the add function was not usable. That's because calling it with the new keyword returned an empty object. But where does this object come from, and why the hell does the new keyword even work?

The new keyword always creates an empty new Object. Why? So, it can give us access to that object, inside the function call.

Let's illustrate it through steps:

1 You call the function with the new keyword:

const adder = new add(1, 2)

2 Now when this code is getting interpreted, as the JS engine reaches the new keyword, it creates an empty object:

*** INTERPRETER MEMORY

ADDRESS: 0x123456789 
=> STORE NEW OBJECT REFERENCE 
=> PROPERTIES: []

This is a very simple illustration of the memory allocation of the new object that is created. This object has no properties, which is shown as an empty array.

3 The function is called, and the new object is passed into it as the this keyword.


*** INTERPRETER MEMORY

ADDRESS: 0x22222222 
=> FUNCTION DEFINITION 
=> CALL FUNCTION BODY 
=> THIS = 0x123456789

... run the rest of function body

So, when trying to access the this keyword inside the function block, it will give you an empty object.

console.log(this) // {}

this is the object that new created.

4 The interpreter runs your function. It evaluates everything and then assigns the value for the adder variable. But what value? Will it be the sum of the two numbers? No. It will be the object which was passed to this. In case of our function, an empty object.

console.log(adder) // {}

Thus, an object is created on the air, and after the function is called, the same object is assigned to the variable.

But what good is this new object for us? The answer is, we can mutate this object. We can add properties to it, and shape what we need to be returned.

Finally, we're on track!

2.4 `this` Is An Object

Objects in JS are mutable. This means, they don't have private or strict members. You can always change a member of an object. Or assign members and values to it.

To create a new object in our constructor function, we've to utilize this behavior. We're given an empty object via the this keyword and then we can shape it as our needs.

So, let's change our add function to make it a useful constructor.

const add = function(a, b) {
  this.first_number = a;
  this.second_number = b;

  this.sum = a + b;
}

As you can see, we don't need extra steps to get access to the object stored in this. We can start on the fly and try adding members to it.

We've added three members to the Object. The first_number and second_number properties store the passed arguments in the object. The sum property is the result of adding them.

Next, we call the function with the new keyword:

const adder = new add(1, 2)
console.log(adder.sum) // 3

Voila! We've done the equivalent of creating a class using the class keyword in ES6+. Indeed we've done what the class keyword actually does under the hood.

Let's try creating another object using the add constructor.

const adder2 = new add(2, 3)
console.log(adder2.sum) // 5

So, we did it. Now what?

3. JS OOP: Behind The Scenes

By this point, we have learned about many things. Including constructors, new and this keywords, and how functions are objects.

In this section we'll dive deeper into the topics concerning how JavaScript thinks about these processes. In short, we want to grasp the concepts!

3.1 Prototypes (again)

I mentioned the prototype earlier in this post. It defines how OOP behaviors like inheritance and polymorphism are implemented in JS.

We'll first have a look at how prototypes can be inspected and altered.

3.1.1 Defining Methods

All that our adder objects have are two number properties with their sum as a third one. This is cool, but not a very useful thing. In a dynamic programming environment, functions are more useful.

What if adder.first_number is updated by mutation, but adder.sum stays the same value? We can change sum into a function:

const add = function(a, b) {
  this.first_number = a;
  this.second_number = b;

  this.sum = function() {
    return this.first_number + this.second_number;
  }

}

We can create a new instance and check its properties:

const adder = new add(1, 2);
console.log(adder);

This will output the following object:

{
    "first_number": 1,
    "second_number": 2,
    "sum": f()
}

So, we can call adder.sum whenever we want and have access to the latest sum of the two numbers in the adder:

console.log(adder.sum()); // 3
adder.first_number = 4;
console.log(adder.sum()); // 6

And as you can see, the sum function has access to the latest value of first_number. So, it will return correct values after first_number is updated.

3.1.2 In Search Of A Better Solution

Do you remember when we talked about instances? In our previous examples each of adder1 and adder2 are instances of the add function. Instance means they each have a new memory address assigned to them.

This also means every property and method that is a member of this object is stored in a new memory address specific to it. This includes the method definitions too. While this can seem reasonable, it isn't the most efficient approach.

Efficiency in this case is concerned with the fact that each time we create a new instance of add, we also utilize a new memory address for the sum method. This is because, as we learned through this post, function definitions are objects and first class citizens. So they will require to be redefined every time.

But what if there was a way we could define this method only once and access it in every instance? Because a function like sum doesn't change every time a new instance of add is created.

The definition is always the same. The only thing that changes is the value of this. The solution in this case is the object prototype.

Let's travel in time and return our constructor function to the state when it didn't still have the sum function definition. We also remove the sum property.

const add = function(a, b) {
  this.first_number = a;
  this.second_number = b;
}

What do you think will happen if we call adder.sum()? It surely throws an error indicating that sum is undefined. But what will exactly happen, before JS throws the error? Does it only check the adder's instance to find sum? The answer is no. It will also look into adder.prototype.

In the next section. We'll review the exact order of what happens under the hood.

3.1.3 The Prototypal Chain

When we call adder.sum() on a version of it that doesn't have sum function defined, JS will do a chain of searches before it returns to us and identifies sum as undefined.

First of all, keep this in mind:

Every object in JS has a link to another object, which is known as its prototype.

Then let's visualize how the JS engine looks for the sum method. For this, we can log the objects in our devtools console to check the output:

const adder = new add(3, 4);
console.log(adder)

This will output the following object:

{
  first_number: 3,
  second_number: 4
}

The above output displays the own properties of the object. Own properties only exist on this instance of the object and have the highest priority in the prototypal chain. The JS engine will look into these properties and doesn't find sum.

But it doesn't lose hope, and looks further, into another object. But which one?

The above output is what the console.log typically shows of an object which includes only the own properties. Our object has another property which isn't listed here. It's the prototype which we can access and read in three ways:

By opening the browser devtools console and typing the above console.log command.
Using Object.getPrototypeOf(adder).
With console.log(adder.[[Prototype]]). This is the property key which stores the prototype object in an instance. Every object has this key.

We'll follow with the second approach as it's a clean one. We run the following statement:

console.log(Object.getPrototypeOf(adder))

Which results in:

{
  constructor: f {}
}

Where does this prototype come from? As every function in JS is an object, every one of these functions has a prototype which initially has one important method. It's the constructor we see in the above output. It's the add function we've defined.

So, every instance of objects returned by a constructor can actually access its constructor function using instance.[[Prototype]].constructor. But it can also access any other property or method set in prototype.

The JS engine will look into this prototype object and still doesn't find a property named sum. So, what next? Does it print the error? No. The engine will continue searching. This time in adder.[[Prototype]].[[Prototype]].

But what is this second protoytpe?

Every constructor prototype, when created, has a link to the global Object namespace of JS. Object is an object by itself. But it's used to create other objects and is the base prototype of all objects in JS.

Let's inspect a log of it:

const adderPrototype = Object.getPrototypeOf(adder)
console.log(Object.getPrototypeOf(adderPrototype)

Do you notice Object.getPrototypeOf? Yes it's the same Object, whose prototype is available in every JS object. The output of the above command looks like the following:

{
  constructor,
  hasOwnProperty,
  isPrototypeOf,
  ...
}

There are a lot of utility methods in this prototype, which we haven't included here. But they're not our concern in this article. What we want to know is what will happen if JS doesn't find the sum method here too?

Well, it will look into prototype of this object. You might think we'll keep this loop forever. But it will end right here. That's because Object.[[Prototype]].[[Prototype]] is null. Which means it isn't linked to any other object.

So every object is linked to another object, if its prototype is an object. If the prototype is set to null, it's safe to say that the object isn't linked to another one.

This is the end of the chain. JS will throw an error and the program exits.

But we've still got things to do!

3.1.4 Adding Members To The Prototype

Like how we altered the this keyword inside the functions we can alter the prototypes too. To do so how we have different ways. For example as we have been using the Object.getPrototypeOf for retrieving the prototype object we can use Object.setPrototypeOf for updating it.

You might also be tempted to mutate the [[Prototype]] object directly. You can do that too. You can set it to a completely different object, create your own chain of inheritances or even make it null, so the prototype won't affect your object.

This means it's a dirty but yet powerful concept. In this section we only want to learn how methods are added to the prototype so they're defined once and accessible in every instance of the object.

Indeed we saw the solution to this problem in the last section, when we were journeying through the prototype chain. You might have noticed when we checked prototype of the adder we got an object that had an instance to the constructor function. This is the best place for storing methods or static properties. Since it's only related to the constructor function and is available to every instance in the first level of prototypal chain.

We can mutate the prototype and add the sum method. It's done quit easily by add.prototype.sum = .... This is a convenient way to add methods to constructor functions in JS.

const add = function(a, b) {
  this.first_number = a;
  this.second_number = b;
}

add.prototype.sum = function() {
  return this.first_number + this.second_number;
}

We can easily check that sum works:

const adder = new add(1,2);
console.log(adder.sum()); // 3

adder.first_number = 100;
console.log(adder.sum()); // 102

This was all that we needed to do. But there's one last thing to check out. The fact that sum works correctly in this example means that when JS finds a method in the prototypal chain of an inheriting object, the this keyword inside that method always points to the inheriting object.

In our example, the inheriting object is adder and the method is in the prototype of the function add's object. But this doesn't point to the function's object. It points to the object, the search started from.

Over.

3.2 Inheritance and Polymorphism

So far, we can create objects from functions, and we can assign methods to them. We have even learned about the Prototypal chain. But did we go through all that hassle, only to learn how to define shared methods for our objects?

No. We can do more. Indeed prototypes make us able to customize our objects in more complex ways. These include inheriting and polymorphism. These are both advanced OOP concepts well-known in most of OOP languages.

First of all we want to learn what inheritance is.

3.2.1 The Problem: Create More Objects, Write Less Code.

The add function does its job very great. And all our adders work perfectly. But what if we wanted to create a type of adder objects which also keep a record of every time a sum was called and the values had been changed.

We can do it in many ways. We can create an absolutely new constructor function, which does the job for us. Or we can change the add function so it keeps the records. But what if we don't want the adders to be able to do more than what they are currently capable of?

Yet the add function shares some of the code we need for the new objects. So, the third way will be a combination of these two.

We don't rewrite the part of code that is shared among the objects. But we create new objects, which in addition to the initial properties can do more advanced things.

Prototypes come to our help. Again.

3.2.2 A New Function.

We start by creating a new constructor. We name it addRecord. As it's the same as add with the difference it records the changes.

const addRecord = function(a, b) {

}

Our function's body, is empty, because we don't yet know how to handle it. First of all we know that we need to reuse the add function. Maybe we can try calling the add function inside addRecord? Let's try that:

const addRecord = function(a,b) {
  const adder = new add(a,b) // But where do we put adder?
}

As you can see we can try creating a new instance of add using new. We even stored it in a variable. But there's a problem. The variable is not a part of our object's instance. Maybe we can try assigning the properties of adder to our this object? But that's not clean and what if we had a hundred properties? Spreading? Seriously? No. These solutions only add references to the instance created by adder. This is not what we want.

Whatever approach we use, we're not going to get a clean object. While addRecord reuses add, it shouldn't treat add as a different object. Indeed it's an altered version of add. It should inherit the behaviors of add.

But how? JS has two interesting methods available for us. They're the call and the apply. Our saviors.

3.2.2 `this`. Again.

Some years ago, when I was reading about the call and apply methods for the first time I had a serious question. While the definitions were clear and I exactly knew what they did, I still couldn't understand what their use case can be.

Well, it turned out they were mainly used in OOP patterns. And they do their job beautifully.

Here's how MDN defines the call method:

The call() method of Function instances calls this function with a given this value and arguments provided individually.

The syntax looks like the following:

function.call(thisArg, arg1, arg2,... , argN)

What apply does is identical to what call does. It actually doesn't do anything different. The only difference is in the syntax. Apply accepts the arguments as an array. it doesn't take them separately. here's the syntax:

function.apply(thisArg, [arg1, arg2,... , argN])

The thisArg is what we're most interested in. It lets us do what we did with new with one difference. new passed a new object as this to add. But with call we can pass any object we want as this. I think you can guess it now.

We already have a this when addRecord is called with new. Why not pass it to add and let it add first_number and second_number properties to the instance created by addRecord?

Okay, we'll do it!

const addRecord = function(a, b) {
 add.call(this, a, b)
}

Then let's create an instance of addRecord and log its properties:

const addRecorder = new addRecord(1, 2);
console.log(addRecorder)

It will output the following object:

{
  first_number: 1,
  second_number: 2
}

But if we inspect its prototype we'll see, it only contains the constructor of addRecord. There's no sign of the sum function again. But don't worry! We don't need to look for it through the whole chain. We'll add it to the chain.

How? We manually link the prototype of addRecord to add.

// after we've defined addRecord
addRecord.prototype.prototype = add

This way, when we later call addRecorder.sum(), it will be found down a deep chain of prototypes. (You can figure it out by yourself)

Mission accomplished.

3.2.3 Everything is a Prototype of a Prototype of a Prototype!

Directly setting a prototype's prototype to a new object, looks a very interesting example of how inheritances can be implemented and mutated in JS.

By now we've only written one line inside addRecord and one line outside of it. And yet we've totally inherited every property and method of add. The next step is to define the recording functionality.

For this purpose we add a new property to addRecord object. It will be an array to later keep the records. The next step will be defining a function to save the result of a sum every time it's called.

We can try defining a new method which has a different name from sum. But that goes against what we're trying to accomplish. The reason that we defined the addRecord in the first place was that we wanted it to be identical to add. The only difference is that when sum itself is called the result should be recorded.

For this, we can define a new method in addRecord prototype and name it sum. It does the job of doing the sum, recording the result and returning it.

const addRecord = function(a, b) {
 add.call(this, a, b);

 this.records = [];
}

addRecord.prototype.prototype = add;

addRecord.prototype.sum = function() {
  const result = this.first_number + this.second_number;
  this.records.push([this.first_number, this.second_number, result]) // add an array which keeps records of current (a, b) and the sum

  return result
}

This should be the complete code of addRecord. Now if we call addRecorder.sum() it should return the result and also save an array of the current (a,b) values and the sum in the records array.

You might be asking yourself how is this sum method useful? Why not just rename it in some other way? Or why not just add recording behavior to the original add function?

The answer actually depends on the design of your application. In our case we want the developers using our code to have access to two different APIs. Both of them are kept really identical. They both take two arguments and they both have the same properties and methods. This will keep the implementation simple for them. Because they won't need to remember two different methods or property names.

This also keeps the behaviors separated. Maybe the add object is used for some anonymous behaviors in which we never want any ways of keeping records. So we don't at all implement the behavior in it.

On the other hand the addRecord function is exactly built for this behavior. It doesn't need too much rewrite and it overrides the sum method, without breaking any functionalities accessible by add.prototype.

by the way, the thing we did by overriding the sum method is called Polymorphism. It means the function does different behaviors in different objects or situations. It was cool, wasn't it? :)

Here's the result:

const addRecorder = new addRecord(1, 2)
console.log(addRecorder.sum()) // 3
console.log(addRecorder.records) // [[1,2,3]]

addRecorder.first_number = 66;
console.log(addRecorder.sum()) // 68
console.log(addRecorder.records) // [[1,2,3], [66, 2, 68]]

4. The End

This has already been a long article. But I have tried to be as through as possible. Because, by learning all of these concepts you actually know what's happening under the hood every time you use the class keyword. Everything we learned about Inheritance, Polymorphism and Prototypes is exactly how the extends keyword of classes works.

Understanding the this keyword and what value it keeps in different situations can come really handy. Besides those things, knowing how functions are more than just functions, can give you a new insight into how JavaScript is actually shaped.

JS can be really strange and crazy at times. But don't forget; it's the same tool that has evolved the web so far. And it's capable of evolving even more!

Thanks for reading this far. And I hope it has been useful to you. If you have any questions, or ideas about what I should write next, reach me in the comments section. I will be glad to answer you!

How to hook into the DOM using Vanilla JavaScript!

MirAli Mobasheri — Sat, 26 Feb 2022 21:04:08 +0000

An element. A very simple element. It's there. Right in the DOM tree. But we want to hook into it. We want to use simple methods to control what it renders. To control when it updates.

If you're a web developer, then you might be familiar with React Hooks. I've also written articles on React Hooks Flow. But this is not about them.

Sure. There's a similarity. They're hooks in React because they let stateless functions use the Class Components abilities like states and lifecycles.

Here we're going to write logic that saves the value or the state of a DOM element and updates it as the state changes. Then this is not about React. But about an interesting way to interact with the DOM. From pure JavaScript!

What are we going to do?

Think of a simple counter app. There are a few elements on the screen to let the user interact with it.

It displays a big number. Which demonstrates the current count.

You click a button and it increments the number. Clicking another one results in decrement. The third button lets you reset the counter to zero.

We're going to create this app. But we're going to do so in a different way. First, we'll write some helper classes to allow us with hooking into the DOM. Then we're going to use them to construct the app logic.

This is how we're going to use those helper classes:

const count = new StateHook("count", 0);

new RenderHook(() => document.getElementById("counter"))
  .use(count)
  .modify((el) => (el.innerText = `${count.value}`));

document.getElementById("incrementBtn")
  .addEventListener("click", () => count.update(count.value + 1));

document.getElementById("decrementBtn")
  .addEventListener("click", () => count.update(count.value - 1));

document.getElementById("resetBtn")
  .addEventListener("click", () => count.update(0));

That's it. Of course, we need to write the HTML part, which is short. And we've to create those helper objects.

This piece of code might seem strange. Even unfamiliar. And that's okay. Because we're going to understand everything step by step.

In the end, you've got a mini helper library that you can extend or use to create new projects.

If you're still in doubt whether this article is for you or not, then let me show you what topics it covers.

What aspects of JS are we going to work with?

DOM manipulation. A very simple example of it.
Classes in JS and their different aspects. Like the public and local properties, inheritance, and chaining.
The EventTarget instance. This is the main part. To be able to replicate the React Hook Flow order, we have to work with events.
Understanding how React applications look under the hood.

If these seem interesting to you, let's move along.

Creating the project

Only three files. I don't want to waste your time with npm and CSS styling. Create a file and name it index.html. The two other files are scripts. We'll name them: hooks.js and scripts.js.

Paste the following boilerplate into index.html:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <script src="hooks.js"></script>
    <script src="scripts.js"></script>
    <title>Vanilla Hooks</title>
  </head>
  <body>
    <main>
      <div id="root">
        <div class="counter">
          <div class="counter__number">
            <p class="number" id="counter">Loading...</p>
          </div>
          <div class="counter__actions">
            <button id="incrementBtn" class="actions__button">
              + Increment
            </button>
            <button id="decrementBtn" class="actions__button">
              - Decrement
            </button>
            <button id="resetBtn" class="actions__button">
              0 Reset
            </button>
          </div>
        </div>
      </div>
    </main>
  </body>
</html>

This HTML structure creates a <p> tag and three buttons. The <p> tag handles displaying the counter's current value and each of the buttons has a different role.

Now let's write some JS code.

The Hooks

We named one of the hooks files hooks.js. This is the file where our app's core logic is going to live. We'll write some helper classes. which are able of listening to events and cause updates in the DOM according to these events.

EventTarget

This is how the Mozilla docs explain EventTargets in JavaScript (read more here):

The EventTarget interface is implemented by objects that can receive events and may have listeners for them. In other words, any target of events implements the three methods associated with this interface.

But why do we need to use them?

An EventTarget interface allows us to create objects which can dispatch events. This means that in any other part of the code you can attach listeners to the events the EventTarget dispatches.

One main parameter in handling DOM changes is to register specific values as states. Whenever these values change, the hooks should reflect them in the DOM.

Then let's start with writing a state hook.

The State Hook

We aim to write a reactive interface for our application. This means that what the hooked elements render in the DOM updates in reaction to changes in our states.

We're going to use EventTargets to write a State class. This class will hold the state's current value and handle its updates. When we try to change the state value, the class instance will dispatch an update event.

We attach an eventListener to the state instance. And fire callbacks when it dispatches the update event.

Let's write the code:

class StateHook extends EventTarget {
  #_value = null;
  constructor(value) {
    super();
    this.#_value = value;
  }

  get value() {
    return this.#_value;
  }

  set value(newValue) {
    return null;
  }

  update(newValue) {
    this.#_value = newValue;
    const updateEvent = new CustomEvent("update");
    this.dispatchEvent(updateEvent);
  }
}

Let's inspect the code line by line. In the first line, we declare a JS class. We use the extends keyword to declare that this class inherits from EventTarget class.

This way our State Class' instances will own the dispatchEvent and addEventListener methods. We can use them to handle state change events.

In the first line inside the class we define a private instance property named _value. When a variable inside a class' enclosing tags starts with the # character it becomes a private property. This means that the only way to assign its value is from inside the class enclosing tags.

This property is the one we use to store the state's latest value after each update. We defined it as a private property because we want it to be immutable like React states.

In the next line, we write the class constructor. It only takes one argument which we name value. This argument is the state's initial value.

We store the initial value in the class's #_value property.

After the constructor we define a get and a set method for the #_value property. We name these methods as value, so that's the name we'll use later to access them.

Now we can access the state value by writing instance.value instead of instace._value. The setter method returns null and does nothing. So that we can never write instance._value = x. Now it's immutable.

And in the end, we define the update method for the state instance. This method takes an argument which we named newValue. We assign this argument's value to the state's private 'value' property.

Then by writing const updateEvent = new CustomEvent("update") we create a custom event with the key 'update'. Custom events are like every other event. They take a name from you, and any Event Target can dispatch them.

In the last line of this method, we dispatch this event. Now we can attach listeners to the instances of this state. And make changes in the DOM using the new state value.

Then let's write the second hook. Which controls what the DOM renders, by listening to the state hook.

The Render Hook

This hook has one simple task. We give it a function by which it can find a specific element. Then we give it specific states which it can listen to their updates. Finally, it gets a function that we call modifier.

It calls the modifier the first time the DOM is ready and then each time the states' values change. It is the hook's task to keep track of the states and call the modifier when they change.

The modifier is a function that the hook calls every time the state changes. So we can use it to control what the element renders.

This is the how we can write it:

class RenderHook {
  constructor(getElement) {
    this._getElement = getElement;
    this._modifier = null;
    window.addEventListener("load", () => this.render());
  }

  use(state) {
    state.addEventListener("update", (e) => {
      this.render();
    });
    return this;
  }

  modify(modifier) {
    this._modifier = modifier;
    return this;
  }

  render() {
    const theElement = this._getElement();
    if (!theElement) return;
    if (typeof this._modifier === "function") this._modifier(theElement);
}

RenderHook is a simple class. It doesn't inherit from EventTarget. Because we have no need for dispatching events from its instances.

It only takes a function as an argument and assigns its value to the _getElement property. Calling this function should return a DOM Element.

In the next line, we define the _modifier property which has an initial null value. It will hold the modifier function which can be set later using a method.

At the end of the constructor, we add a listener to window's load event. The instance's render method will run for the first time as soon as the DOM is loaded.

After the constructor, we define a use method. It accepts a state argument. The argument should be an instance of the StateHook class. Then we add a listener to its update event. Each time a state updates it calls the instace's render method.

At the end of this method, we return this. You might wonder why we do so. This way we're returning the current instance. This benefits us while calling this class' methods as we can use chaining.

Chaining is a more declarative way of calling an instance's methods. To see the difference, look at the following example. It tries to add three different states to a RenderHook instance:

const counterRender = new RenderHook(() => document.getElementById("counter"));
counterRender.use(counterState);
counterRender.use(timeState);
counterRender.use(styleState);

The code can be shorter and more concise by using chaining. Each time we call the use method it returns us a RenderHook instance. So we can attach each method call to the previous one. Resulting in the following code:

new RenderHook(() => document.getElementById("counter"))
  .use(counterState)
  .use(timeState)
  .use(styleState);

Now our code looks clean ;)

Next comes the modify method. It takes a function. And assigns it to the current instance's _modifier property.

And the last method in the line is render. It's the base of this concept. It's the promised one. The one who does the final job.

You give it no arguments. Call it and it will proceed to update the DOM. To do so it uses what data you have provided using the other methods.

First it calls the _getElement function. Then assigns the returned value to theElement variable. Then it checks if theElement is not nullish. That can happen in case the element has been removed from the DOM.

It calls the _modifier function and passes theElement to it. And the modifier can proceed to do its job. Which could be updating the DOM.

And that's all!

How it works.

Once more let's look at the final code I showed you at the beginning:

const count = new StateHook("count", 0);

new RenderHook(() => document.getElementById("counter"))
  .use(count)
  .modify((el) => (el.innerText = `${count.value}`));

document.getElementById("incrementBtn")
  .addEventListener("click", () => count.update(count.value + 1));

document.getElementById("decrementBtn")
  .addEventListener("click", () => count.update(count.value - 1));

document.getElementById("resetBtn")
  .addEventListener("click", () => count.update(0));

Now it shouldn't seem confusing anymore. We define a state using the StateHook. Its initial value is 0. Then we create a RenderHook. We pass it the function to get the counter text element.

We tell it to use the counter state and start listening to its updates. And we give it a modifier which it should call each time the counter state is updated.

In the next three lines, we use simple JavaScript. We find the button elements in the DOM and attach listeners to them. Clicking the increment button increments the count state's value using its update method.

We configure the two other buttons in a similar way.

Every time we call the state's update method it dispatches a Custom Event. This event's name is update. This dispatch invokes our RenderHook's render method. And in the end, our modifier updates the text element's innerText.

The End.

(Cover photo by Vishal Jadhav on unsplash.)

A Story Of React Effects.

MirAli Mobasheri — Sun, 05 Dec 2021 20:36:32 +0000

We use states to update what components render. But what if some operations don’t cause immediate changes in the component’s output?

The React documentation calls them side effects. And some examples include using web APIs, handling HTTP requests, and attaching listeners to events.

For handling these, React provides us with the useEffect hook. It calls the function you pass it each time the component renders or updates. Through this article, we’ll learn why React implements this functionality.

And when you finish reading this you can start to use effects to your profit!

Side effects

Every action ends in an outcome. And every component renders an output. To lose weight, you need to burn fat. It’s possible by going on a diet and beginning exercises.

But get ready for the side effects.

These side effects include headaches, fatigue and, dizziness. They are so because they are not what you expect. Neither are they a part of the main routine.

When exercising exhausts you, you need to rest for a while. You need to gain energy before you can return to your everyday life.

In a React app, when requesting data from the server, we can face the same problem. Because we're not sure how long it can take to retrieve the data from the server. And we're not sure if we can render it in the component's output.

So we call the useEffect hook to start fetching the needed data from the server. In the meanwhile, the component renders a placeholder output. You know what it is.

A beautiful loading indicator!

The useEffect Hook

From the React documentation:

By using this Hook, you tell React that your component needs to do something after render. React will remember the function you passed (we’ll refer to it as our “effect”), and call it later after performing the DOM updates.

So you pass a function to useEffect, and it remembers to call it after each render or update. This means that by the time the component calls your effect, it has already updated the state. And the browser has finished painting the screen.

But why do we need to wait for the render to finish before running the effect?

We can find the answer.

The variety of side effect

Think of a big drapery shop. Full of luxurious and colorful textiles. Rows over rows of fabrics. Silks from all over the world. A great show of human creativity.

Now imagine the customers. A market welcomed by women. Waves of them coming to the store and leaving hourly. Think of how the owners can manage the purchases and the sales.

Then there's one special case. One of the customers, a young blonde lady, is looking for a rare type of silk.

It was in stock three days ago. But now, all of it was sold out.

So the salesman takes the lady's phone number. Then he makes phone calls with some well-known silk traders to order a new set of that special silk.

In the end, he informs the lady that he'll call her later as soon as the product is available. (And let's hope he doesn't text her: "How you doin?"!)

A drapery shop could run out of any of its products at any time. Do you think the manager should not open his store if some of his assets are missing?

Does the above question make any sense to you? By waiting for the perfect time, he may not as well make more than ten sales per week.

A React component is like this drapery shop. It renders what it has in stock. And if data isn't currently available in the state, it renders a loading indicator. Then tries to fetch the data in a useEffect hook.

A code example looks as following:

const Drapery = (props) => {
  const [isLoading, setIsLoading] = useState(true)
  const [data, setData] = useState(null)

  useEffect(() => {
    fetch("https://example.com/endpoint")
      .then(res => res.json())
      .then(data => {
        setData(data)
        setIsLoading(false)
      })
      .catch(error => console.log("There was an error while fetching data", error)
  }, [])

  return isLoading ?
    <Spinner /> :
    <ListComponent data={data} />
}

This code renders a component with two states.

One of them is loading. In case its value is true, it means data isn't available. So the component should render a loading indicator. The other one is data which holds a list of drapery items. And ListComponent is going to render them.

We should focus on the useEffect part. The hook accepts two arguments; a function and a dependency array.

The function holds the logic of your effect.

Using the dependency array, you pass a set of values that React will start to track. Anytime any of the values in this array changes, React calls your effect.

In this case, we've passed an empty array as a dependency. This indicates that React calls this effect only once. That is after the initial render.

If you pass no dependency array to the hook, React calls the effect after each render or update.

The function we passed to useEffect tries to start fetching data from the server. JS fetch API returns a promise. We use it to update the states as soon as we get the response.

We update the data state with what we get from the server. Then we set the loading state to false. Then the condition in our component's return expression evaluates to false. That’s when it renders the data using ListComponent.

While our effect causes a re-render by updating states, it doesn't affect the render. It runs in parallel. And it never causes any direct changes in what the component renders.

In the previous section we had a question. Why should effects run after the render is updated?

In this case, a good reason is that network calls can affect the client's performance. We need to show the loading indicator as soon as possible.

In web apps, each second lost due to performance is thousands of potential users lost forever:(

How much did we make today?

A drapery shop's manager needs to keep its daily sales data in a secure place. He needs to have a record of everything they buy and sell daily.

They save pieces of information on every new asset they deliver and sell daily. They should do it as soon as any change occurs.

While writing React web apps we sometimes need to save the user's data in the client's storage. The localStorage API is a good option for this case.

We can use the useEffect hook to listen to changes in state as soon as it is updated. Then we can set a JSON clone of the new state in the client's storage.

An example:

const UserContext = createContext()

const UserProvider = ({children}) => {
  const [user, setUser] = useState(null)

  useEffect(() => {
    const persistedUserData = localStorage.getItem("user")
    if(persistedUserData) setUser(JSON.parse(persistedUserData))
  }, [])

  useEffect(() => {
    const jsonUserData = JSON.stringify(user)
    localStorage.setItem("user", jsonUserData)
  }, [user])

  return (
    <UserContext.Provider value={{user}}>
      {children}
    </UserContext.Provider>
  )
}

In the above example, we are using React.createContext to initialize a context. If you don't know about context, you can think of it as an API. It makes the value you pass to its Provider available to every component in its tree. To learn more you can read the documentation.

Then in the body of the Provider, we have used three hooks. One is a useState which holds user info. Its initial value is null, which means no user data is available.

The two other hooks are both useEffects. The first effect runs only after the first render, as its dependency array is empty. We use it to check if there's any user data previously stored in the client's storage. If so, we parse the JSON data as a JS object and update our state with it.

The second hook has a dependency array with one element: user state value. So it will run every time we update the user state. This effect makes a JSON copy of the user state and saves it to the client's localStorage.

The second useEffect is a good example of when we should use effects. We update the client's localStorage, which causes no change in the render. There's no place for its logic in the component body.

We've also learned how we can control when effects are run by setting their dependency arrays.

Good!

Did a fire catch here?

Silks, clothes, curtains. They're all so soft and lovely. Yet they're so vulnerable to ignition. A small flame can turn the whole drapery into ashes.

Piles of money, into ash, that is.

A drapery shop's manager is aware of this hazard and takes every precaution step needed to prevent its occurrence. But there's always a chance of a mistake. And a mistake is enough to undo all the cautions.

So he has specified an explicit procedure for when fire catches in the store. And he has instructed it to his employees. In addition, he has printed them on paper and stuck them on the wall.

There's little chance of things going wrong, but it might happen at any time. And he needs to bear it in mind.

Do you need a similar web app example? A text editor is one.

When working with a text editor, you need to save your changes to not lose them when you reopen the text. Now there's a chance you forget you haven't saved your changes and click the browser's close button.

A good web application is going to prevent this disaster happen. It stops the navigator from closing the tab and alerts you that you haven’t saved your work.

Sir or madam, truly your forgiveness I implore, are you sure you want to continue?

To implement this feature in a React app we can do it with useEffect like the example below:

  const Editor = (props) => {
    useEffect(() => {
      window.addEventListener("beforeunload", showDialog)

    return () => window.removeEventListener("beforeunload")
    }, [])

    return <EditorPanel/>
  }

In the above example, we attach a listener to window's beforeunload event. This event is fired whenever the user tries to close the browser or the current tab.

The useEffect hook is a good choice in this case because the component is already rendered. Then we're sure that the window object is loaded and we can attach an event listener to it.

Also, we've used a return statement in the useEffect hook. You can always return a function in your effect. React will call this function when the component is unmounted.

We returned a function that removes the event listener attached to the window because we don't want to prevent the user from exiting the app when there is no editor open.

A function you return in your effects is called cleanup function. Since effects like this listener are out of the component's scope and are not related to its render, it's always a good idea to write a cleanup function for them.

When a drapery shop's manager goes broke and has to leave his place, he also has to clean the wall from his emergency instructions. The new manager won't like to see them there!

That's it!

In this article, we learned why we need to separate effect logic from render and how to do it wisely. We also learned different use cases of this feature and how to handle them correctly.

I hope you liked it.

One last word. If you were in doubt whether you should write an effect or just bring the logic inside the component's body, ask yourself this question: Is the operation immediately going to change what the component renders?

In case this article was of any help to you, I will be glad if you follow me on Twitter or mention me in an appreciation tweet. That means a lot to me!
@MobasheriMirali

A Story Of React States.

MirAli Mobasheri — Sat, 27 Nov 2021 20:13:09 +0000

It's hard to maintain a state. Harder to maintain a UI. And near impossible to keep a user happy.

No matter how well you plan, disintegration always happens.

React is a well-known web UI library with a long history of state implementation. Components shape the application. But it's a state's job to keep it inside the sanity borders.

That is unless it drives the developer insane before achieving this goal!

Different seasons, different states.

We know how the seasons pass. In spring, flowers bloom. In summer, sweats run down the armpits. With autumn, leaves leave the branches. And who will forget the snowy days of winter? (Hint: People who live after global warming makes its debut!)

Nature can resemble a big React Component. A part of life on Earth. But it goes through various phases. We know each as a season.

Different parts of a front-end application can be in different phases too. They are the results of changes in what we call a state.

An introduction to our study.

Imagine a man with a bad temper. He swears in hot summers. And beats people when it gets cold enough. No one can predict him.

You might say that he is affected by the weather.

For example, he is a kind man during springs and even sings poems when it rains. Winters are cold and make him impatient. That is why he will prefer to get his deals done by action rather than talks.

Such a man lacks good state management, making him unable to control his behavior. A similar issue can exist in a front-end application too. That’s when it gives inappropriate responses or gives none at all.

Then, let's have a quick review of what a state is in a React Component.

React Components State.

From the React documentation:

State is similar to props, but it is private and fully controlled by the component.

Props themselves are Objects. Their keys are the name of the attributes we pass to the component through JSX. And their values are that of the corresponding attributes.

While a state can be an attribute or a collection of them, it can be an Object, a String, or any other JavaScript Type. But what is the main difference between a state and a prop?

Answer: The component receives props from its parent, while it creates and controls its own state.

What is the actual problem?

At this point we can ask a question: What makes a great application?

Perhaps dedication to its end. The desire to deliver satisfaction. A sense of being useful. What we may call confidence.

A bad application isn't pushed by these things. It already feels satisfied and confident. It is directed by more solid things. It is affected by data flows. By a powerful inertia.

It's uncareful about user expectations. And it's rarely suited for different user stories. It only works if everything is ok. Which is seldom the case in a real world application.

Can we make a state using a simple variable?

Let's say that we've a component called Nature. This component has a main state variable: season. First let's declare it just using a simple JavaScript variable:

function Nature(props) {
  let season = 'spring';

  return(
    <p>Currently it is {season}</p>
  )
}

The line const season = 'spring'; is where we declared our state variable. The output HTML looks like this:

<p>Currently it is spring</p>

Let's add a button to our function's return. We pass its onClick event a callback which will try to change the variable season's value to 'summer':

function Nature(props) {
  let season = 'spring';

  const changeSeason = () => {
    season = 'summer'
  }

  return(
    <div>
      <p>Currently it is {season}</p>
      <button onClick={changeSeason}>Click to change season!</button>
    </div>
  )
}

It will output the previous result with an added button. Yet if you click on the button, it won't change the season's name in the output.

The variable's value changes to summer but the onClick will never result in a change in the output.

Why?

To answer that we should learn about React Hooks Flow. This is where things get interesting.

Stories of a component's madness.

Events. A sequence of them shapes what we may know as a storyline. For example, you may have just graduated from high school. This is an important event for you that also describes your level of education.

Our memories and personalities are made of events. Our resumes are fully contented by them. And to get our life move on, we expect future events too.

A Component's lifecycle is full of events. We're going to have a look at an example.

Assume a submit button which is used to register user information. The button is disabled until the user fills the required fields correctly. The form component uses a state variable to enable the button.

It works just fine. The user fills in the form. The gray button turns blue and the user clicks on it. In the background the API request for registering is sent. But the user is not informed. They don't see any loading element or message.

They think it hasn't worked and they click on it again. And guess what! Another request is sent in the background. The first request is successful to register the user.
The component is designed to redirect the user after success. But...

The response to the second request comes in a hurry. Acknowledging the component that the user's email is a duplicate. Now another state variable holding the email duplication error, turns true.

The component gives the user an error informing that the email is a duplication and the redirect just doesn't work because the error state is not false. The component has been instructed not to redirect if the error state is not clear. Which is irrelevant. And is a bad state management.

We're faced with several events in this example. One of them happens when the form is filled. Another occurs when the user clicks on the button. The last event is when the response has arrived.

We as users and developers can understand these events. But a UI library such as React is not as smart as a human. It has to be instructed what the events are, and it has to register them beforehand.

That's what we call Components Hook Flow.

React Components Hook Flow

Hooks were added to React from version 16.8. They were a major update at the time, as they empowered the stateless function components with abilities that were only available in Class Components.

It was a good thing to have the ability to run effects and change states in a functional component. But a Class Component also provided the developers with Lifecycle Methods, eg. componentDidMount or shouldComponentUpdate.

The functional components and hooks don't provide us with Lifecycle Methods. Instead different hooks in a functional component are run in a specific order so that the developer can implement the same Lifecycle Logics by considering this order.

The Hooks Flow is made of 3 main stages: Mount, Update and Unmount.

When a component mounts for the first time, its initial values are set. These include the useState and useReducer initializer functions. Then it will continue the rest of the codes you have added in your functional component, up until it reaches the returned value.
Then before rendering the returned JSX, it will run your layoutEffects which you create using the useLayoutEffect hook. Then the browser paints the screen to reflect the React Virtual DOM. Then the effects which you have registered using useEffect are called.

It's a straightforward flow for mounting the component. But then the component will need to update. This can happen due to two reasons: either there's a change in props or a state has been updated.

The updating stage has its own steps: It will run your functional component and update the DOM based on the new changes resulting from the updated state.
In the next step, it's going to clear the previous layoutEffects, afterward, it will run the layoutEffects. The browser repaints the screen to reflect the changes.
And finally, before running the effects, react is going to clean the previous effects.

The updating stage has a similar order of steps to the mounting one. It only differs in the details. Like, the mounting stage uses initial state values, and the updating stage uses the new ones. The mounting stage runs the effects but the updating one first will try to clear the effects caused by previous updating or mounting stages of the component.

The third stage in this flow as we mentioned is the unmounting stage. In this stage the whole component will be cleared from the screen. So nothing is going to happen, except that React will try to clear any remaining layoutEffects and effects.

Now that we know the React Hooks Flow, we can realize why storing our Component's state inside a simple variable won't cause a change in the DOM.

Because React won't update the DOM, unless it is sure that something has changed.

The way React listens to the state changes is like how we can add eventListeners in JS. For example, assume a text input element. We can add listeners for its value change, or when the input is blurred.

React adds listeners to the state variables' changes. And when we call the stateSetter functions, this event is fired, and then React knows how to update the DOM.

Then, let's rewrite our previous code to make it work.

The right way to declare a state

React provides us with the useState hook to bring states to functional components. To initialize a state you need to call the hook and pass it the state's initial value.
The hook will return an array of two elements. The first element in the array is the state's value and the second element is the state-setter function.

We'll use this function to add the season state to our component. We'll also rewrite our changeSeason function to use the state-setter function returned by useState.

function Nature(props) {
  let [season, setSeason] = useState('spring');

  const changeSeason = () => {
    setSeason('summer')
  }

  return(
    <div>
      <p>Currently it is {season}</p>
      <button onClick={changeSeason}>Click to change season!</button>
    </div>
  )
}

Now after rendering this component if we try to click on the button we'll see the season name in the paragraph changes to summer.

In the above code, the variable season refers to the first element returned by useState which holds the latest state value. And setSeason is the method we can use to update the state's value.

We learned how we can bring states to a functional component in React. And we've also learned how states work in a more fundamental way.

Knowing the right way to declare a state, a great question pops up: Is there also a right way to use states in React?

Life is a journey (So is React development)

No one is like anyone else. No one shares the exact same interests as anyone else. We're all unique through our preferences. And this uniqueness also affects the way we live our lives.

Different React projects also have their own differences. They differ in how they manage their states, their effects, their components trees, or even their folder structures.

No one state that you should structure a React project in a specific way. You have to understand the underlying mindset which React uses for managing its re-renders, props, states, effects and etc.

Throughout this article, we learned about the mindset behind how React implements states. I hope it can help you to better understand what they are and why they matter.

This is already a long article and I'll end it here as I don't want to bore you with extra information. But let me add one more tip. Anytime you were in doubt whether you should use a state or not, try to answer this question: Should changes in this variable cause a re-render?

Credits for cover image: M. Schuppich/Shutterstock.

I have no content creation experience in English Twitter yet. But I'd like to start tweeting about different subjects of programming in my Twitter account. I'd really be thankful of your support if you start following my twitter account:)

The Story Behind JavaScript Promises - A Use Case Based Approach!

MirAli Mobasheri — Sat, 07 Aug 2021 16:35:44 +0000

❓ Why should you read this?
🏇 In a hurry?
🤝 How Promises Are Made: Please Put A Ticket!
🔛 Main Usages Of A Promise: Making API Calls.
✅❌ Callbacks: The Green And The Red Button.
↩️↪️ Callbacks: Then & Catch.
⛓️ The Methodology Behind Promises: Returning Objects!
🕸️ Static Methods: Promise.all & Promise.allSettled
🏃🏻‍♂️ Static Methods: Promise.any & Promise.race.
🔚 Promise Callbacks: finally.

The young librarian felt satisfied with what she did. Sarah had started her job when she was only 22 years old. Having known her as a long-time member of the library, the kind Mrs. Perkins hired her.

Mrs. Perkins had been the library's manager for as long as 30 years.

Now Sarah was the main person responsible for the place. She did a great job. People liked how she treated them and controlled everything.

But it didn't take long before things got out of control.

Mrs. Perkins retired. The girl had to do everything alone. And a new wave of readers was joining the library. She couldn't deliver services anymore.

She was forced to make promises...

❓ Why should you read this?

This might seem a long article. And the story might look unrelated.

But let's face the truth. How many times have you learned a concept but have never used it?
Perhaps there were situations where you could use Promise.race. But you didn't. Because despite you knew what it did, you weren't sure what its use case could be.

And when you got into a problem which you could solve using Promice.race, you chose to go your own way. Because you weren't even sure if it was useful there.

You knew what it did. But you didn't know its use case.

Here, I'm presenting you with a story. It also teaches you about different ways you can use Promises.

But it also tries to symbolize its use cases through a real-world story. Next time you face a similar situation you'll be quick to know how to handle it. And if not, you have at least read a story!😉

Enough talk. I have promises to keep.

It started with the Covid-19 pandemic outbreak. Everyone wanted to pass their quarantine by reading books. But no one could go to the library due to the health restrictions. They had to keep social distance.

Then Sarah came up with the idea to make an online deliverance system. Anyone could use the library's website to reserve books.

She thought that she could deliver the books on her bike to their door front. And as the transportation cost her time and money, she took a very small amount of dollars for her service.
But she wasn't always online and couldn't plan every books' deliverance on time. She had to deliver them herself and close the library since no one took her place.

She needed extra help. Somehow.

🏇 In a hurry?

I have separated everything into different parts. Each of them is about a specific side of the Promises. So you can skip any part you are confident about.

Already know how to make JavaScript Promises? Skip the introduction part!

She called her cousin and asked him if he could design an ordering system for the library's website. She described the process as: "People will have to log in to their accounts. And if there is a book they want to request, they should put an online order ticket for it."

But since it was not clear when she could deliver the books, the users had to wait for the website to notify them.
It sent a message. If the book was available to deliver, it informed them she had resolved the ticket. Otherwise, it contained a rejection message.

She named it the Promise System. Likewise the JavaScript API we're going to learn about.

Let's dive in!

🤝 How Promises Are Made: Please Put A Ticket!

To create a JavaScript Promise you can use the new keyword:

const thePromise = new Promise()

The Promise Object Constructor accepts a function as an argument. This function runs the process that we're going to promise its fulfillment.

In our story, the way Sarah manages the ordering through tickets resembles such a Promise. Either it is fulfilled with the book's delivery or rejected for a reason.

This function can in turn accept two arguments: resolve and reject.
Both of which are callback functions that we can delegate on certain points.

We use resolve as a fulfillment signal and pass it the final data. By calling reject we make clear that the Promise has failed.

From what we've learned we can construct a Promise by writing the following lines:

const theOrderingProcess = (resolve, reject) => {
  // The process with the unknown duration.
  // Function body goes here.

  // If anywhere in your code, 
  // you think your promise is fulfilled, 
  // (e.g. Sarah finds an ordered book is available),
  // you can call resolve and pass it 
  // the data you would like to return. 
  // Like the following:
  // resolve(theBookData)

  // But if somehow the promise has failed to fulfill, 
  // (e.g. A book is currently borrowed),
  // you can call reject and
  // pass it the reason to rejection:
  // reject(theRejectionReason)
}
const theWebsitePromise = new Promise(theOrdeingProcess)

Every time someone put a ticket for a book, he/she had to wait for a certain process to come to an end.
It was not as if you selected a book and immediately had it on way to your home. Things took time. How long? No one knew for granted.

Mrs. Perkins wasn't an all-up-to-date lady. So she had stored most of the data about the existing books and the borrowed ones in an old Access database. It took time to transfer them to a server. And Sarah wanted things to get done as soon as possible.

She had to use the Access database. By herself.

🔛 Main Usages Of A Promise: Making API Calls.

Nowadays most websites use a database on their back end side. Like how Mrs. Perkins stored the library's data in an Access database.

Of course the website databases use automations!

A web application's front end needs to send a request to a server endpoint to receive some data. Then using this data the application can deliver its services.

As the front end sends the request, the process mounts into a pending status. It will stay in this status until it either receives a response from the back end or receives none.

The pending status could take for an unknown period. This depends on the networking conditions of the user and the server, and how fast they can transfer data. Additionally, the back end itself might need to process some data and take extra time.

An example of sending a request using the JavaScript Fetch API looks like the following:

const theRequest = fetch("https://example.com/endpoint")

The fetch method constructs a Promise Object, and returns it. So we can use its returned value same as a simple Promise Object. Helping us to get rid of creating our own Promisess.

Want more comfort? Use axios.

The library's online ordering system took tickets from its users. They contained information about the user and the selected book. Sarah reviewed the tickets. And checked for the books' availability in the Access database.

If everything was okay, a green button labeled as resolve, awaited Sarah's click. Otherwise, the big red button was ready to delegate a rejection event.

No one knows for sure. But rumors are there was a black button too. For dark purposes. Unknown.

✅❌ Callbacks: The Green And The Red Button.

We call the processes like the API requests Asynchronous Operations. They vary from the Synchronous ones which are simple Program Expressions.
A Synchronous Operation takes a constant time to complete. The system runs them in a sequence. It waits until the execution of one is complete before it runs the next.

A Synchronous Operation looks like the following:

const x = 10;
const z = function(num1, num2) {
  return num1 + num2;
}
const sum = z(x, 20);

Every line of this operation is predictable. The compiler will be executing each line one after another. There's nothing unpredictable that could block the program's main thread from running.

But an Asynchronous Operation can block the program's execution. This is so because its fulfillment depends on the network conditions and speed. Even if the user owned a fast network, the back-end servers could be facing trouble. This can result in no response or a longer-running process.

How can we write an Asynchronous Operation and make sure that it doesn't block the rest of the code from running?

The answer is: "by using Callbacks".

Of course, while it sounds like a heartwarming name, wait until you are caught in a callback hell!

When the user put a ticket for a book, he registered for future events. He was awaiting a response to his request.

Either this response arrived, or some problem prevented it from ever coming.

Now the user was using a true Promise System. The library's website provided this system. But the user didn't have direct access to the promise. He was listening to it.

Then the user had to make his own plans based on this Promise. He was telling himself: if the reply was a successful message then I'm gonna return my last book. If not, then I can choose another one. Maybe the reply never came, or the website's server went down. This problem will catch his eyes, and so he was going to call the librarian and inform her.

console.warn('I never got a response!').

↩️↪️ Callbacks: Then & Catch.

If you use the JavaScript Fetch API, it will return a Promise Object by default. You don't have to write the Promise yourself. You have to listen to it. How?

Every Promise returns an Object. And this Object owns 2 important methods. then and catch. You can use these methods to attach callbacks to a Promise. You pass them a function which will be called as soon as the Promise delegates an event. What events?

You can call the resolve callback inside a Promise Function's body and pass it what data you want. Then the Promise calls the callback function inside the first then call and passes the data to it. The Promise calls the catch method as soon as you call the rejection callback.

Let's visualize this process by an example:

const request = fetch("https://example.com/endpoint")
request
  .then((data) => data.json())
  .catch((error) => console.log("Error in fetching the request", error))

Here we call the fetch function and pass it the endpoint URL.
The fetch function creates a Promise Object and returns it.
We store this Object in the request variable.
We call request's then method and pass it a function. The function can receive as many arguments as it expects. It retrieves those arguments from what the Promise passes to the resolve callback. Then the given function can do as much as it desires with the given data.
Next, we call request's catch method. We pass it a function. And expect the Promise to call this function when it rejects or the then method throws an Error.
In the end we run the code to see if it works. Of course it does. And if not, we won't hesitate to point our finger at the back end:)

A question exists. The then and catch methods only add callbacks to the Promise Object. So why aren't they properties to which we can attach the callback functions? Wouldn't it be simpler?

We'll find the answer.

Everything Sarah did resulted in a Promise.
Hitting the resolve button was only the first step.

She had to find the book in the library. She had to package it next to the other ones which she had to deliver the following day.

She had to mark each package with the right user's information. This included their names and addresses. She had to be careful when she loaded the packages on the bike. Not to disturb her ride.

She had to ride through streets and alleys. Dodging traffics and caring for her safety. Reaching her destination, she had to ring the doorbell. If the client was present, then she delivered the book.
And then she took the reader's previous book to return it to the library.

After repeating the same routine for every client, she had to finally go back to the library. She placed the returned books on the shelves. Then filled the Access database with data about the returned and the delivered ones.

After all, it was time to review that day's orders and check for their availability. Then managing to hit the resolve or the reject buttons.

Even the rest she got by her night sleeps, was a promise she had made to her body.

And it feels good to fulfill promises. Doesn't it?😊

⛓️ The Methodology Behind Promises: Returning Objects!

We've faced a question. A matter which insists that providing callbacks through methods is useless. The Promise API can instead provide special Object Properties. Or the ability to add an array of callbacks, for another instance.

But think of all the possibilities you might face while developing front-end applications. You won't always want the callbacks to run in order. You might not remember a case for this at the moment, but sure someday you'll face it.

Different scenarios need different approaches. And if the Promise is going to be of any help during these situations, it has to be flexible.

Let's have a look at a piece of code:

const aPromise = Promise.resolve("resolved")
aPromise.then(res => console.log(res))

Here we have been able to use the Promise's static resolve method. Without even having to construct a new Promise Instance we were able to return a Promise Object.

Now we can call this Object's then method. Or its catch one.

Well, what good is that for? You may ask. To find the answer let's have a look at another example:

const firstPromise = Promise.resolve({message: "hello"})

const secondPromise = firstPromise
  .then(data => JSON.stringify(data))
  .then(json => json.indexOf(message) !== -1)
  .then(boolean => {
    if(boolean) console.log("JSON string was created successfuly!")
    else throw new Error("JSON creation error")
  })
  .catch(error => console.error(error))

const thirdPromise = firstPromise
  .then(data => {
    if(data.message) return data.message + " world!";
    else throw new Error("The data doesn't contain a message!")
  })
  .then(newData => console.log(newData.toUpperCase()))
  .catch(error => console.error("Error in third Promise", error))

Here, we've initiated a Promise Object using only Promise.resolve. This promise object gives us all the superpowers we want. We can call its then method as much as we want, in a chain or in separate calls. This allows us to create various waiters for the same process. What is a waiter?

Let's say you have got to fetch data, which you will use in different parts of your application. But there's a problem. You can reuse synchronous operation data as in variables. But you can't do that with asynchronous data. You should wait for it to become available.

Now, there are different parts in your project, awaiting this data. We can refer to these parts as waiters. They're observing the Promise's status and as soon it settles, they will read its data.

The above example showcases how the then and catch methods help you to reuse the same data in different scenarios.

This way the Promise API is providing an easy-to-use solution.

But it also provides us with some useful static methods. We can use them to handle different situations. They include: Promise.all, Promise.allSettled, Promise.any, and Promise.race.

Every day, to return to the library Sarah had to make sure that she had visited every one of her destinations. If all the clients were present at home, the book exchanges were successful. Otherwise, some of them failed.

She didn't need every deliverance to be resolved. She needed to have finished the process which was about going to the client's house.

In the end, she returned to the library. And when she was ready to enter the reports in the Access database, she would ask herself: "Was everyone at home? Did any of the orders remain undelivered?"

She classified the undelivered books in a separate database. And she sent the clients an Email that expressed the situation.

If she had delivered every book then, she only had to set that day's deliveries as done, in the database. Nothing further to take care of.

🕸️ Static Methods: `Promise.all` & `Promise.allSettled`

The all method accepts an array of promises. Then it waits for all the promises to resolve. If any of the promises rejects, it will immediately return with the rejection reason.

This function behaves like what Sarah asks herself every night: 'Was everyone at home? Did any of the orders remain undelivered?'

She will know that she has done all her tasks once she delivered the last book. If so, only the clients' returned books would be on her bike.

Promise.all resolves once every Promise in the promises array passed to it resolves. It returns an array of what each promise had returned. Like the books that the library's clients returned.

Sarah immediately knew that the delivery has failed If none of the clients were present at home. She would return with the undelivered book still on her bike.

If any of the promises you pass to Promise.all rejects, it will immediately reject. With the rejection reason of the rejected promise.

An example of Promise.all usage:

Promise.all([client1, client2, client3])
  .then(returnedBooks => console.log(returnedBooks))
  .catch(rejectionReason => console.log("Error: a book was not delivered.", rejectionReason))

We said that Sarah's return to the library didn't depend on every client's presence. She needed to make the visit. So if she had toured around all the clients' addresses, she was ready to return to the library. And on her bike, she transported all the books. Whether returned or undelivered.

For a likewise behavior with JavaScript Promises, we can use Promise.allSettled.

Every Promise passes through two main states: pending and settled. The settled state is when the promise has been fulfilled. The settlement either happens with resolve or a rejection.

The all method immediately returned when a Promise rejected or every promise resolved.
But the allSettled method immediately returns. When all promises have either resolved or rejected.

When they are settled indeed.

What the allSettled method returns in its resolve, consists of an array of objects. Each object has a status property which is either fulfilled or rejected.

If the status is fulfilled then the object provides a value property too. Otherwise, it owns a reason property.

A demonstration of it in code:

Promise.allSettled([client1, client2, client3])
  .then(books => 
    books.forEach(book => {
      if(book.status === "fulfilled") {
        console.log("A returned book", book.value)
      } else {
        console.log("An undelivered book", book.reason)
      }
    })
  )

Soon enough troubles showed up.

The website's users had to wait a long time for the response message's arrival. Then they started to see more rejection messages. No matter what book they ordered, a rejection message awaited them in their inboxes after 1 to 2 days.

Some of the users tried to contact Sarah through Emails. But they only got a simple reply. It stated: "The requested book is currently borrowed by someone else. You can try to order it later, or borrow another one."

These replies worsened the situation. It surprised the clients that Sarah didn't even state when the book will be available. Or whether she could put them in a queue.

Everything seemed unexpected and random.

Sarah at first didn't notice any issue. She was still taking books for some people. But later it caught her eyes that things were getting weird.

Before anything started to happen she wanted to find a solution to speed her routine up. She called her cousin and asked him if he could help her in searching the current Access databases. She needed to be quicker in finding out if a book was available.

He said he would look into it and call her as soon as he found anything. The next day he had a solution. He could write a python bot which would search every Access database. And to speed things up, he had found a useful algorithm for it too.

He made the bot ready within a day. It searched the Access files for a specified book name and stated whether it was available to borrow. His special algorithm indeed created several asynchronous operations.

It searched each file in real-time with the others. As soon as any of the files contained a search result matching the book, the bot took it. Then it terminated all the search operations.

She had separated the Access files into two different directories. She named one of them the library books and the other the ordered books.

Books in the ordered books' directory were currently ordered or delivered.

The library books databases had a list of all books in the library. It also contained information on whether a book was available or not.

While developing his bot he had decided that the result was either in the ordered books databases or the library ones. If it was the ordered ones then it was obvious that the book wasn't available and Sarah had to reject the ticket.
Else if it found the result in the library databases it was either available or not.

This speed the search up because the ordered databases were smaller than the other group. So if it found a match result among them it terminated the searching quicker.

But two weeks after the new bot's implementation most of the orders had to be rejected. She had had a regular delivery count of 9 to 10 books per day. Now, this number had fallen to as low as 3.

Some days none at all.

Many of the borrowed books remained unreturned for a long time. Their owners didn't even order new ones.

And then she heard rumors. One of her best friends had tested positive for Covid-19. The infection statistics were surging in her town. She called some of her customers to ask why they weren't trying to return their books.

Her suspicions proved right. Covid-19 had hit many of her customers. But some other ones were actually bothered with the site's functionality. They hated waiting a long time for no results.

She tried to talk them back into using the library's website. She even promised that she will fix the issues. But promises weren't convincing anymore.

One night she called her cousin. Tears in her eyes. "I failed.", she said. The confession feeling bitter. "I failed badly."

🏃🏻‍♂️ Static Methods: `Promise.any` & `Promise.race`.

Promise.any accepts an array of promises. And resolves as soon as any of them fulfills.

The library's users chose a book and ordered it and waited to see if it was available. If not, they would go for the next one. But this process took a long time. They had to wait for each order's message to arrive before they could decide anything.

And when the system became unresponsive it wasted the users' precious time by days and weeks.

What if they could find a way to order many books together and get the first book that was available? Of course, it was impossible with the library website's architecture. Sarah wouldn't have allowed this. This could ruin all her plans.

But this is not the case with JavaScript. If you are waiting for the first promise that resolves, use Promise.any. It works the same way as the hack the library users wished for.

An implementation of Promise.any:

Promise.any([order1, order2, order3])
  .then(order => console.log("this order resolved first", order))
  .catch(error => console.log(error)
    // expected output: "AggregateError: No Promise in Promise.any was resolved"
  )

As soon as any of the promises resolves, the Promise Object calls the callback passed to then. If all reject, it enters the catch territory.

Then there is Promise.race. It resolves with the first Promise that settles. In case you've already forgotten, a Settled Promise is either fulfilled or rejected.

Now, why should someone need to implement that? It's actually difficult to name a good use case for Promise.race. But still, there are few times when it could be of help.

Let's think about the bot that Sarah's cousin had developed. It exited the processes as soon as any of them returned anything. You might say that the bot's actual action is like what Promise.any does. It returns as one of them fulfills.

Then it can be a bad example. But let's say that the Promise which he used to search the ordered books didn't fulfill when it matched a book. Let's say Sarah's cousin was smarter and played a trick on it.

If the search in the ordered books matched a result then its Promise rejected. Otherwise, if it had searched the entire databases and found none it resolved. But, if the search process related to the library books found a match and it was available then it resolved. Otherwise, the Promise rejected.

So here we have got a bright point. The rejection of one of the promises means the resolving of the other one. And vice versa.

Now, Promise.race can help us in reducing the time we need to wait for a useful response.

Let's have a quick look:

Promise.race([searchLibraryBooks, searchOrderedBooks])
  .then((book) => console.log("Book is available."))
  .catch((reason) => console.log("Book is not available, because ", reason))

The library books have an alphabetical sorting. The ordered ones are sorted by their order date. So it's possible that the search in the whole library books could make a quicker match sometimes.

It didn't take long before Sarah received a phone call from his cousin. He sounded anxious. And when she asked him what was wrong, he replied: "The bot had a bug, Sarah. There are always several versions of a book in the library. This means that if someone borrows one of its versions the book could still be available. I hadn't thought about this in my code. If one version of the book was ordered then I tagged it as unavailable. I'm sorry Sarah."

Sarah was in shock for several seconds. How didn't this even cross her own mind?
"Can you fix it?", she asked.
"Well I'll do my best.", the other replied.
"Then you better do it.", she couldn't control how loud her voice got. "And do it as soon as possible!"

It took another day for them to fix the issue. She sent Emails to her clients. Informing that they have fixed the issue. And the users could start using the website immediately.

🔚 Promise Callbacks: `finally`.

We learned about then and catch. But the Promise Object also provides us with another method. It doesn't care if the Promise fulfills or not. It only cares that it settles. And any then and catch calls have already been delegated. Then it runs and does what you ask it for.

An example:

const websiteDelivery = Promise.resolve({useServerDatabase: false})
websiteDelivery.then(condition => {
    if(!condition.useServerDatabase) console.log('Use Access database')
    else throw new Error('Data isn't still moved to the server')
  )
  .catch(error => console.log("Error in starting delivery website", error))
  .finally(_ => console.log("No matter if you lost 100 times. Try for the 101st time!")

The Promise Object calls the function you passed to the finally method in any condition. After the Promise settles.

"The devil is always in the details." This was what Mrs. Perkins told Sarah after she heard her story. She went on: "You saw the big picture. You wanted to start a movement and to modernize our town's library. But you forgot the details my dear. You told yourself that you can handle the database work. But this was something you had to leave to the programmer. After you've finally restored the library's daily life, I hope you've learned something. And I hope that this damned pandemic ends very soon."

Sarah hoped too. And she smiled.

It was a long read. And a longer one to write. I think it was worth the time.

The hardest part was about Promise.race. I could hardly find a good use case for it. And I hope the idea I came up with could help you make a picture of it.

Do you think there are better use cases for any of these methods? Or do you think I have gotten something wrong?

Please let me know in the comments. Writing this article helped me a lot in understanding the concepts myself. Your comments can help me and the others further too.

Thanks for the reading.

The cover image is by Epic Top 10 Site.

How technology and programming can benefit workplace safety.

MirAli Mobasheri — Sun, 13 Jun 2021 16:27:37 +0000

Cover image's source: skycatch

Every organization needs to take workplace safety seriously. Working in a safe environment results in improved work quality and is what every employee desires.
Higher health and safety quality results in productivity improvements since healthy employees are more productive and will cause a positive impact on the company’s core process. On the other hand, if employees feel insecure at work, productivity is minimized.

After reading all of this, a question might occur to the reader: While every industry is quickly developing and technology is becoming the main subject in specialized work, how can we use it to improve the quality of workplace safety?

In fact, what solutions does technology offer to extend the quality and usability of work safety?

Technology in the industrial context.

Reading the above headline, probably the first thing you think of is the fully robotic process lines of the factories or the industrial design and assembly applications. Or you might think of the automated vehicles or Elon Musk's SpaceX rockets, pursuing the dream of inhabiting Mars. Yes! All of these are examples of the technology’s industrial usages.

But have you ever wondered how a company ensures a worker’s safety among their factory’s giant machines? How could this benefit from technology?
Basing several astronauts on a space station, how is their safety provided and secured? How is it that NASA measures Mars’ surrounding for its robotic probe from thousands of miles away and ensures its safety? Or how does the company utilize its drones to study the safety of the future of human life on Mars?

Many questions exist. Industrial safety is a broad topic. And maybe someday we will need to take care of our robots’ safety in addition to that of the human. In this article, we will learn about some technology examples that can be helpful in the workplace safety field.

Realtime Connections

High-speed communication and networking tools can have an essential effect in improving workplace safety. Too many risks surround the workers who need to work in remote environments.

One of the technology examples I mentioned was about how NASA ensured its probe’s safety on Mars. To communicate with its probe on the surface of the red planet, the organization has set up an extensive communication chain called the Relay Network.
It includes two satellites in orbit around Mars that receive commands from Earth and send them to the probe. Images and scientific data received from the probe will be sent back to Earth by the Relay Network(Learn more on NASA’s website).
This way, NASA can receive the instantaneous conditions of the rover and safely steer and control it by sending scheduled commands.

Currently, the Internet is the most widespread real-time communication tool on Earth, allowing people to connect regardless of their location. Industrial organizations can easily use this powerful tool and the communication platform it builds to communicate with their employees.

Communication apps and tools can collect real-world data, enabling employers to be aware of their employees' safety status. Employers must be able to receive up-to-date information about the workplace’s safety and health status. They can achieve this by using connection technologies.

Web applications can be an effective tool in this field. The web is a platform that can run on any host, enabling responsive and effective user interfaces.

For example, NASA has announced they intend to launch their central control system, which is an open-source application for various platforms such as desktop and mobile. They have based it on web technologies using the VueJs web programming framework (More information).

This shows how the web and its programming languages’ flexibility can facilitate the development of communication tools.

Safety Applications

The intention behind the development of safety apps is to simplify the access to information needed about the risks involved in a process.

These apps receive the information related to your projects, create a database of it, and by examining various cases, allow you to predict possible risks or accidents.
They organize safety checklists, store photos of work phases, measure the project’s progress, and convey the state of the risky steps.

These tools are very helpful in managing occupational safety and health and facilitate the process of taking care of operations.
Mobile apps development has become much simple than in the past, and its users are expanding rapidly.

And in the development community, new technologies and solutions have been introduced that can help to develop a comprehensive application suitable for several target platforms using one programming language and developing under one platform.

This is exactly why an organization like NASA uses a web framework for its central control system application.

3D Visualization

Three-dimensional modeling can help employees in a work environment to learn more about the workplace and to be aware of the possible dangers.

For example, if the SpaceX company decides to test its space rockets, a visualization of the launch environment can demonstrate the rocket launch process to personnel. Then they can obtain a safe radius by examining the likelihood of a problem or an explosion and use this visualization to prepare the test environment to prevent any casualties or side effects.

Employers can also use this technology to train employee safety. In three dimensions in a reality-like environment, It is possible to convey the steps required to get the job done securely and identify the hazards and accidents that are likely to occur.

In other cases, we can use simulation to design an industrial process and pre-test safety in a specific environment. We can also benefit from it to maintain inherently safe workplaces and chemical processes, which depend on the structure and the building of the workplace ( to design an inherently safe process, we should get rid of every predictable risk factor in its prototype stage).

Designers have been using 3D design software for a long time. But what has recently made 3D models more widely used than before is their use in the context of the web. This way, advanced modeling can be performed and reviewed in any environment without the need for advanced devices.

As in the case of a worker who wants to review a particular operating method in his work environment and remember how to do it safely, watching such models through smartphones can accelerate his work.

Augmented Reality and Virtual Reality

Safety training and learning is the first fundamental step in developing a safety culture, but as the saying goes, experience is the best teacher.
Yet, in the matter of safety, one cannot rely on experience alone. An unsafe experience can be too painful and lead to horrific events such as amputation or chronic illness.

Virtual reality can help people observe and experience various situations, including dangerous events, and acknowledge appropriate reactions in a 100% safe environment by placing them in a virtual simulation.

Artificial Intelligence and Machine Learning

We may argue that artificial intelligence and machine learning are not directly acceptable as safety technologies. But, predictably, these topics of computer science will have a role in improving safety technologies.
We use safety as a science to prevent the occurrence of risky probabilities. And when it comes to probability and statistics, computers come in handy.

For example, one of the difficulties of safety in the workplace is monitoring all available situations. On the other hand, many accidents occur due to inattention or distraction of human operators.

As a solution, we can use drones equipped with cameras that can monitor various processes in a workplace. Then by using computer image processing, artificial intelligence analysis, and machine learning, the system can check whether a potential risk or danger exists or not.
In more detail, with the help of artificial intelligence, this drone can detect whether a worker is wearing gloves in a situation where it is essential to wear them or whether they have dangerously left work waste in the process’s route.

Conclusion

We learned how modern technologies help facilitate the process of assessing and identifying the hazards in a workplace.
The above is just a glimpse of examples of these technologies. In future articles, readers can expect a deeper and more comprehensive explanation of each of these technologies and the new ways of their utilization.
At an applied level, these technologies can attract Industrial Safety and HSE activists. And at a basic level, most of them require programming, computer, and network knowledge. I will try to cover both of them in future articles.

Artificial intelligence and machine learning subjects are among the important ones that lead every technology’s future. The world is moving towards automated and error-prone work routines, and certainly, in the near future, these subjects will change the way we implement Industrial Safety. That is why I will continue to write about them, as they are in my interests too.

This article was originally published on the HSELand blog.

And I appreciate Sandra Melo’s article on mydatascope which inspired me in writing this post.

👨‍🔬 Why The DOM Causes Negative Enthalpy! - Learning Frontend Deeply - Part 2

MirAli Mobasheri — Sat, 24 Apr 2021 20:23:11 +0000

Why Should You Care About The DOM And The Negative Enthalpy?

In the first part of this series, we learned that HTML is a Markup Language destined to create documents. We now know that this document is much like a paper one. We can use different elements and layout systems in HTML to shape our ideal document layout.
But still, there's a question. If it's only about documents, then humans have been able to create them thousands of years ago. Documents can be carved on stone, painted on papyruses, and written on paper.
So while HTTP facilitates the document's sharing around the world, there's one important thing that a webpage needs to be capable of to ultimately become superior to a simple document.

And it is the ability to update data in real-time, in response to user interactions and different events. This feature makes documents interactive and pushes the limit of the traditional documents which could never be edited or updated. And especially this is one of the main skills every frontend developer should acquire.

Throughout this article, we are going to learn about the Document Object Model abbreviated as the DOM. In the last part, we learned about the Document, now we'll try to figure out what an Object is and how the DOM implements the Model.

But we're not going down a straightforward path. We're going to learn about some basic theories of computer programming. This includes variables, objects, collections, compilers and etc. This is because I want to show you how in the end all of these theories shape the internal functionalities of a web frontend application.
This is somewhat like how we're introduced to Christopher Nolan's Tenet. It's going to show you some theories and in the end, you are going to face it all in real action. Then let's dive deeper!

First questions first...

🏍️ What Is An Object?

While a motorcycle has two wheels, a car holds four. Both are objects. Each with its traits. These traits could vary in numerous ways.

The comparison we made identifies the difference in the count of common property in two distinct objects.
A contrasting case is the observation of a hen and a motorcycle. Both can move. And while the hen utilizes its legs for this purpose, the other uses its wheels. The movement action is possible for both of them, but they do so using quite different tools.

❗ In terms of programming, we can express the actions as Methods and the tools as Properties.

Thus, the main element in Object Definition is that a set of traits shape the object.

By knowing what an object definition is, let's move on to how a document is defined by it.

🌴 What is an object model?

C is a programming language. So is C++. Both are known as semi-low-level languages. This means you'll need to write thousands of lines of code to make a simple program work. But in exchange, their programs run at higher speeds. Because by writing code in a low-level language the system needs less translation of your code to understand what you're trying to assemble.

But there is a major difference between the two languages we talked about earlier. C++ is an object-oriented version of C. What does this mean?
This means that we can define objects in C++ programs which possess their own traits and actions.

Let's define object orientation in smaller chunks. That'll make it easier for you to grasp the idea if you don't already know about it.

First, let's begin with a simple thing; Value. That's what every program is about!

2️⃣ Hey PC, Take This 2!

In a program, every value is stored in a part of the memory. This value is identified by a reference. A reference is a specific number that addresses a location in the memory that holds a specific value.

This referencing can be suitable for performing actions like computing. For example, if you want to calculate the sum of 2 and 3, you have to store these values in the system and then give the system the program by which it should add these two numbers.
A reference to the value 2 could be a number like 2452123 and a reference to the value 3 could be another number like 7892392.

The system can manage these references easily. But it would be hard for a human to work with them. We'll easily forget which reference points to which value.

🤙 Call My 2, Ey!

A variable is simply a name we give the reference to a value. In the last paragraph, we said that in an exemplary system a reference to number 2 is 2452123.
Now, what if we told the system that we want this reference to be called a; so that every time we had to point to this number we simply give its name and the system retrieves the value for us?

How variables resemble humans' memory. (Click to learn more.)

This behavior is close to how we humans store different data in our minds. For example, when we want to refer to a long fruit with a yellow cover, we say banana. The value was retrieved!

🎙️ Hey PC, Repeat After Me: Ey equals 2!

Fortunately, most of the programming languages manage this for us.
Here's how we define a variable in JavaScript:

var a = 2;
var b = 3;

In the above code block, we've declared two values, stored them in memory, and given them a custom name for their references. Thus if we wanted to add these numbers we simply tell the system: add a and b.
In JavaScript it's written like this:

var c = a + b;

What happened in this code block?(click to learn more)

Here, in a single line, we've performed three actions. First, we've retrieved the two values 2 and 3 from the memory, by calling their names. Then, we've added these two numbers which result in a new value, 5. Next, the new value is stored in the memory and its reference is given a name; c.

Well, we gave the references a name. But what does it have to do with Object-Orientation?

⛏️ The Thing, or The Object?

So far, we've only defined simple variables. These may be the basics of programming, but they are insufficient for a more advanced program.

Metal is one of the most useful materials in construction but by giving a fair look at the world around you, it's easy to conclude that buildings aren't just made of metals. They're assembled of glasses, metals, concrete, etc.

The same observance applies to a program. It's never made of single values. But rather a collection of them.

👨‍👩‍👧‍👦 [Person 1, Person 2, Person 3]

You know people by their names, phone numbers, looks, jobs, and much more. Perhaps you know a lot of people. Hundreds of names could be familiar to you.

Indeed you have got a collection of information in your memory. A collection of names, or a collection of different brands. All in all, collections are the main way of information storage.

What makes collections suitable for this purpose is their flexibility and simplicity in integration. You can easily search, sort, filter, or manipulate a collection.

📊 Data Structures

Probably, algorithms are familiar to you. If not, you can think of the following text as an algorithm:

Go to the kitchen. Search the cabinets for the red pepper can. If found, swallow the whole can's content. If not, go to the freezer. Take out all the ices in it and swallow them one by one.

As you can see, an algorithm is a set of step-to-step commands. Computer programs are instructed using these algorithms.

Let's think about the sum program which we previously wrote using the variables. Its algorithm is straightforward. Take the first number and add it to the second one. Store the result in a new memory location.

But is there a collection too?

🔢 Arrays

Sometimes you need to store different values as a group. Like a list of different versions of a sentence. You can store each value in a separate variable but that's not the ideal way. Because for instance, if you are required to iterate over the list and find a specific version, you'll have to check each value manually to find out whether it's the wanted value or not.

Arrays come to help.
An array is indeed a list of memory addresses. Of course, these memory addresses refer to values. But its difference with a normal reference is that it can be indexed.

What is indexing? And how does an array work? (click to learn more)

Simply it's like when you are looking at a list of different versions of a sentence and you ask your colleague about which version he likes the most and he responds: 'The third one!'
So, the keyword here is third.
Now if we wanted to represent the version history list in a JavaScript array, it would look like this:

var versions = [
  'A sentence.', 
  'Beautifully written sentence.', 
  'Da Funny Sendenze!'
]

To access the second sentence and store it in a new variable the following line of JavaScript suffices:

var theDesiredSentence = versions[1]

In JavaScript arrays are indexed from 0 which means that the first element's index is 0 and the nth element's index is n-1.

The array is a very simple collection. But remember when we talked about the calculation program. It didn't consist of any arrays. Perhaps we could use an array of numbers and write a program to calculate the sum of all of the numbers in the array. But that's not what we're trying to do right now.

The question was whether, in that simple program, a collection existed or not. Now, none of the values were collections, but in reality, the whole program is a collection.

Why is that?🧐

🔁 Program Compilation

Every program written in a language has to be compiled into machine language to act as fast as possible. The machine language is the most direct one, but having the lowest level among the programming languages, it's not possible for programmers to easily interact with it.
The nerds' solution to this problem has been the development of higher-level programming languages. Yes, even C++ has a higher level in comparison to that of Assembly.

Still, there's a matter to reflect upon. If communication with machines is difficult then how comes the compilers do it and turn huge chunks of code into machine-readable ones?

To understand the mechanism you can think of yourself trying to speak a foreign language, how will you manage it?
First, you will create mental models.

What is the mental model? It's the concept or the meaning of what you are trying to translate.

How is a mental model designed? Suppose you want to tell a foreigner that his face is burning. What is the concept behind this sentence? A face that belongs to that person is melting due to contact with heat?
But what is the context? Perhaps you and the other person are trapped inside a burning house and you are screaming at him to warn him that his face is burning. Or maybe you are pushing his face into boiling water and joyously shouting: "Ha! Ha! Ha! Your face is burning!"

Do you see? Different contexts. Different tones. Different sentence structures.

Now how are these related to a compiler's task? Well first of all it gathers every value in your program. These values are like the meanings of every single word. Next, it tries to shape a model of your values. This model is shaped from the different scopes inside a program code.
Scopes are different blocks of code inside a program. These blocks contain standalone logics, which can perform independently of other parts of the code. Sure most of the time the blocks will use variables defined in other scopes or passed as arguments.

The compiler will look for the various blocks present in a code to shape its model. These blocks will help in maintaining the levels of the model. Previously we learned about arrays which are the most common forms of collections, but the ones we spoke about were only one-dimensional. However, in cases in which we need to specify a collection of groups of values, we can simply nest arrays inside each other.

In JavaScript a nested array might look like this:

var nestedArray = [
  [1, 2, 3],
  [4, 5, 6]
]

In the above code example, the nestedArray variable could be a model of various values organized in different blocks. Like block 0 and block 1 and so on. This way the compiler will know what block each value belongs to. So if somewhere in your code you try to call a value that isn't available in the corresponding block, the compiler will throw an error.

A nested array might be a good example to illustrate a collection model, but not perfect for such a case as a compiler's model. Because arrays are just a group of values in a specific order.

Thus, the programmers have designed various types of data structures that can be used to implement collections in a useful way. Examples of these data structures include linked lists, queues, stacks, graphs, and hash tables.

What Data Structure Does A Compiler Use?

Compilers mainly use Symbol Tables as their primary data structure.
A Symbol Table is a symbolized collection of data. Don't panic if this doesn't make sense to you, we're going to learn it in more detail.

⚛️ What does symbolized mean?

Remember when we talked about variables?
We stored a value in the memory and then gave it a name. So each variable in a program is made of a group of information that includes: memory reference, name, type, and attribute.
Using these properties, the compiler can store what information it requires about a particular variable in a single symbol and then implement these symbols into a bigger model which represents the code blocks and scopes, using a data structure.

A representation of Symbol Tables could look like this:

<symbol name, type, attribute>

What are the type and the attribute? (click to learn more)

JavaScript is a dynamically typed language, which means that you don't have to strictly define a variable's type. But under the hood, each value owns a type. There are several built-in types like objects, strings, numbers, etc.

These types declare the intrinsic behavior of the variables. So in a `Symbol Table`, each value holds a type declaration. The attribute is another unpopular term in JS. In languages like Java, keywords such as `public` and `private` exist that can be used in a variable declaration to indicate in what context the variable can be used.

The `let` and `const` are the two attributes that can be used in JS. For instance, using the `const` attribute clarifies for the compiler that the variable can't be assigned a new value after its initial declaration.

What data structure a compiler uses for shaping the code blocks, can vary between Linear Lists, Binary Search Tree, and Hash Tables based on the compiler's architect.

💼 Is a data structure enough for a compiler to get its job done?

The short answer is no.
The long answer is that a data structure is only a model that makes data available to you. It exposes no methods to work with the data. It's barely a skeleton of data.
A skeleton doesn't move by itself. It can take no action. A body needs muscles to be able to handle its skeleton for good use.
Hence the compiler uses its own built-in methods to work with the data that is exposed to it through the symbols.

How is this data structure is similar to a database? (click to learn more)

Each symbol is an entry and each code block is called a block. You could think of a symbol table as a database. Indeed I can relate to this personally since I'm currently working on the development of a web-based database management application for the place I work at.
Each cell in a database table is like an entry. A cell can be a text, a number, a date, and many more fields. Each of these fields has its own type and attributes. Each table can also be divided into different phases with each phase having its own rows of entries.
But a database management application isn't made up of just entries and phases. It's also about the ordering of data, its aggregation, editing, inserting, removing, validating and etc.
Each of these functionalities can also be generalized to how a compiler commonly behaves with a symbol table.

⁉️ What now?

This was a long read, but not a useless one. We have learned about the program's compilation progress, and we've come to acknowledge what a data structure is and how an object is defined.
Now, it's time to get back on track and learn how a Document's Object Model is implemented.

But first, let's take a few seconds and think about the answer to a fundamental question of the frontend area.

🤷‍♂️ Is HTML a Data Structure or is it an Object?

It's tempting to say that HTML is an object since it possesses traits like a body or a head or a title. These may sound like traits being defined for an object.
But they're not and HTML is definitely not an Object. It's a Data Structure. All that HTML does is expose data.

Indeed you the developer who writes the HTML are exposing this data to the browser. Using the document structure which we talked about in the last part, you were doing the compiler's job.
Oh, yes! Perhaps you have written several HTML documents, or maybe you're an experienced one, and using the HTML markup has been a daily job for you. But you have never thought that you were indeed writing a pre-compile file. That you were doing the programming process with a negative enthalpy!

Sounds crazy and sounds like what Christopher Nolan introduced in his 2020 movie; Tenet.

You have come a long way to reach this point, and perhaps you are tired or you think this article will be useless. Yeah, I know! This idea is turning around your head that I've been mocking you all the time. That compilers and data structures and the Object Orientation have got nothing to do with a simple HTML.
But be patient my dear reader. From now things only get better.

After all, what do you expect from a Nolanish idea?😎

SPOILER FREE: I'm not going to spoil anything from the movie's plot. The negative enthalpy theory is something you learn very early in the movie. So enjoy the article!

🔀 But how is the negative enthalpy happening?

A chemical reaction with a negative enthalpy is one that loses energy throughout the process.

This might sound too theoric but we can interpret it in our subject as such:

When we code a program and the compiler turns it into an executable file, we're keeping energy by doing less work by ourselves. The compiler is the one that handles the hassle of translating our code to machine-readable programs. Now, when we write HTML, we're losing energy. Because we're doing a part of the compiler's job which is creating a data structure. We're doing more job to model the fine Document Structure for our purpose.

But the Data Structure isn't the only thing that the compiler creates. There was actually a need for different methods to be able to work with this data.
This is where the Document Object Model comes into play. And to no surprise, this time we're going to work with objects.

🗜️ Where are my methods?

So, you give the browser all the data necessary in your document, organized into nested structures, according to your desired layout, and expect the magic to happen.
But that's not what every application is about. Is it? Nowadays web applications are more than just scientific documents. They're about Interactive Interfaces which respond to user interaction.

Documents get updated, changed, inspected, animated, styled, and manipulated in real-time. If you think of the HTML Document as the Symbol Table then by using the DOM Methods to work with this data structure and to change it, you are doing the compiler's job.
Because you are managing the available data structures and methods to output your desired program.

But there is one important difference. The compiler compiles once, you do it many times.

What Next?

Originally this post was intended to have full coverage of all the methods that the DOM avails us with. But tonight I decided that writing such a long article might not be a wise move and might result in the dear readers' attention loss.

So our long journey comes to a pause with the knowledge that the management of a frontend application is like a real-time compilation. In the next part, we'll learn about the DOM's methods and compare each of them with what a compiler does.

The next part is more like an action ride through how updating a document's different parts, results in different states, and perhaps Tenets!

And I expect the next part to be released faster than this one. Since most of it is already written!😁

The End!

And don't forget to give me feedback. I'm trying to bring new ideas into this series and like everyone else my ideas have their own flaws too. So I would be glad to hear what you think!😅

🗿 Why Humans Invented HTML - Learning Frontend Deeply - Part 1

MirAli Mobasheri — Tue, 02 Feb 2021 20:18:28 +0000

Why Should You Read This?

If you have ever watched Kubrick’s 2001: A Space Odyssey, you should’ve noticed its popular cutscene, in which an ape-man throws a bone into the sky and when the bone reaches it’s climax, it cuts into a scene in which a spacecraft is accelerating in the space.

It contains an indirect and heroic message: “The same ape-man who threw a bone into the sky, out of joy and curiosity, was also the same man who sent spaceships to the outer space.”

It’s the idea of evolution. How humans learnt to develop better solutions and tools, based on their past discoveries and knowledges.

But how can all this stuff be related to HTML? We’re living in an age, where the web is rocking! There are web apps, websites, blogs, e-commerce stores, social medias, web games and much more. How could such a thing be related to an ape-man and his bone? The answer lies in how and for what purpose and based on what concepts, previously developed by humans, HTML was introduced.

And this is what we’re going to learn about in this post. Fasten your seatbelts as we’re going to have a blazing journey throughout the history of HTML and the World Wide Web foundation!

❓ How Can This Article Be Helpful To You?

This article is not a tutorial or doesn't try to teach you writing HTML. Of course in the future parts of this series, codes and tutorials will be added to the content too. But for now I would just like to demonstrate a deep picture of HTML and its purpose and foundation. If you've just started to learn web development, it can be a good help for you. And if you're currently an experienced frontend developer, it can extend your view on the web development environment.

❓ Why Am I Publishing This Series?

Because after I had succeeded in an interview but had lost the job in a week, I was motivated to learn everything related to frontend, deeply and bit by bit. In this series I will share with you the experience and the knowledge I gather along this journey. You can read more in this article: Why I Succeeded In The Interview But Lost The Job!

Before We Start...

Question: Like everything made by humans, HTML too has been developed in order to overcome a challenge. But what was the challenge and how could HTML specifically help to solve it?

The short answer is that: HTML is the human solution for sharing documents. It's a Markup Language that simplifies the process of structuring documents that can be shared on the context of the World Wide Web.

But the long answer is something more thorough. We should first learn how HTML was developed...

👨‍🔬 Born In A Physics Laboratory❕

No. HTML wasn't meant to create webpages by using the energy released from atom excitation. But it was founded by Sir Tim Berners-Lee, who was in a position in the computing services section of CERN (the European Laboratory for Particle Physics in Geneva, Switzerland) in order to ease the process of document transportation.

❓ What made Tim feel the urge to create HTML? (click to expand)

CERN was a center for the gatherings of top physicists where they discussed and exchanged revolutionary ideas about things that can evolve and revolute the life on earth.
Thus we can conclude that documents, like official ones or articles or manuscripts or etc. had a great usage in their gatherings.
But what if they could get rid of all the hassle of accessibility to these documents and save their valuable times for thinking on theories that could end human life on the earth with an easy swipe of particles, instead of waiting to reach Geneva and discuss for long hours with other scientists who would stubbornly never accept their theories?

Hence Tim came up with the idea of a kind of a Hypertext which could behave like a paper document and let the reader navigate the pages and the contents by clicking on what became to be known as Hyperlinks. And all of these documents were going to be transferred through HTTP (HyperText Transfer Protocol), which helped the physicists access them around the world by having an internet connection.

Surely, the internet we're talking about was different from what it looks today and the initial web browsers and webpages had many differences. Tim's idea for the HTML Document Type Definition was a blend of SGML and Hypertext. But what are these two? Let's find out together.

🦸‍♂️ Hypertext: Texts That Only Superman Can Read

In defining Hypertext we should note that the word "Hyper" isn't used in the sense of a very long text or something that is about 1 million of words. Of course the internet and the Hypertext are useful tools that facilitate the access to billions of pages of documents, but Hypertext specifically means: "Documents that contain special anchors to other documents. These anchors can be accessed via mouse click or keypress or touch screens. Activating these anchors would make the browser jump to another document."

The Anchor Tag ⚓ (click to expand) <a href="http://example.com">Link Text</a>: The <a> tag is one of the main HTML tags. The word a is the first letter of 'Anchor'. And it accepts an attribute called href which stands for Hypertext Reference and it's value is the destination to which the browser must jump, upon the anchor's activation. This tag will render a link on the Hypertext document, whose address is the href's value.

The Hypertext terminology had been known among the academics since the 1940s. But it wasn't until the first graphical PCs came to life, that Hypertexts could become a reality.
The development of Hypertexts on PCs included document files which consisted of buttons by clicking on which, the system decided what content had to be displayed. Those were buttons like next page and previous page or Chapter Titles in a table of contents.

Yet these Hypertexts only worked on a PC and couldn't access documents on other PCs on the other side of the world. For this, Tim decided to implement HTTP.

Explaining what HTTP is and how it works, is out of the scope of this article. We will learn about it in some future articles of this series where we shall read about ajax.

Then let's see what a Markup Language is and how SGML inspired Tim.

🧾 Markup Language: How To Define Elements In A Document

I have many times come across people on the internet who debated whether HTML is a Programming Language or not. To me the answer can be found as easily as looking up it's name.
HTML stands for Hypertext Markup Language. Well, the name itself doesn't claim it's a programming language but instead it's a markup one. A markup language is a human-readable text that uses tags to define elements within a document.

For a better understanding you can have a look at the current post. There's a title which says 'Why Humans Invented HTML'. Now let's suppose that we need to print a copy of this post and we fancy the title to be printed on the top-left corner of the page. The position is set beforehand in the printer, but the printer needs to know what the title is. Instead of passing the title to the printer separately, we define it in the document itself. But how?
That's where the Markup Language comes to our rescue.
In the text containing the Markup Language we define a title tag and pass it the title we desire. The printer, while parsing the text, would store the value for the title and print it in the correct position.
Here's an example:

<title>Why Humans Invented HTML</title>

The above example uses HTML tags. But since there are different Markup Languages, we could use any of them in their own respective environment.
The following is an example of the Scribe Markup Language:

@Title(Why Humans Invented HTML)

So now that we have a good idea of how a Markup Language defines elements in a document, let's find out what SGML is.

📋 SGML: The Way Markup Languages Should Be Defined

SGML stands for 'Standard Generalized Markup Language'. It's not a Markup Language in itself, instead it's a standard registered by ISO (International Standard Organization) which defines the standards for a Markup language.

How can SGML be useful?
If new Markup Languages were about to be developed, this standard can be applied to them in order to make the Markup language supported on different platforms. Since the Markup languages based on this standard behave close to each other and obey the same rules, they can easily be ported to different formats and be printed easily. That's how HTML can easily be transformed into PDFs, EPUBs, XML and etc.

The SGML itself was developed based on GML (Generalized Markup Language), earlier developed by IBM for it's printer devices. A document's structure in GML might look like this:

:h1.The Title Goes Here!
:p.A paragraph about the content.
:h2.A title for a list.
:ol.
:li.List Item 1.
:li.List Item 2.
:eol.

What's the ':ol' Markup?
❗ Notice how ol (ordered list) is used to start an ordered list and eol (end ordered list) is used to declare that the list element ends there.

The Markup would print the following document:

The Title Goes Here!

A paragraph about the content.

A title for a list.

List Item 1.
List Item 2.

SGML replaced :tagname. :etagname. with <tagname></tagname>, which was also implemented into HTML.

Now a new question pops up. How did HTML implement SGML?

✅ HTML Comes To Life.

When Sir Burners-Lee, first began to publicize his idea about sharing Hypertexts through the internet, it became well known among the researchers who taught it would become the main communication tool in the future.

What did companies think about the HTTP at first? (click to expand)
The big companies like HP or IBM saw it useful only for the researchers who wanted to share their documents and make referencing simpler. To them, the communication future depended heavily on the telephone companies and the solutions they could find for its development.
Well as it turns out they were wrong. Right now the WWW is the home to billions of websites, which nowadays are about more than just the research and the official documents.

But even so, Tim was alone at first. He had to use his own computer abilities to bring his concepts into reality. He blended other concepts like Hypertexts, SGML and etc. and also developed his own sharing protocol which is HTTP. Then he was able to gather small teams and develop the world of communication!

But what did the HTML look like at the beginning?

HTML: The First Version.

For a real example you can visit this page: The World Wide Web Project
The above link will redirect you to the first page ever written in HTML. If you want to see how the page was Marked up, you can do so by right clicking on the browser page and selecting 'View Page Source', or other options like this.

We can have a close look at it's source:

<HEADER>
  ...
</HEADER>
<BODY>
  ...
</BODY>

The source as you can observe consists of human-readable tags. There are two main tags: <HEADER> & <BODY>.

Now that we've learnt that a Markup language tries to stimulate a paper document, we can easily understand what these two tags are about. They define the two main parts of a document: 'Details' & 'Contents'. It's like many document folders you can find in offices and schools and elsewhere. Chances are you have yourself written such a document too.

What does 'Header' really do?(click to learn)

The details that the <HEADER> tag gives are different from what we need to know about a paper document. The <HEADER> part actually isn't meant to be read by humans. It contains information that a browser might find useful. Like what? Like a 'title' or a 'character set'.

Let's zoom into the <HEADER> tag:

<HEADER>
  <TITLE>The World Wide Web project</TITLE>
  <NEXTID N="55">
</HEADER>

Since this is a very elementary version of HTML, just two tags have been defined inside <HEADER>.

One of them is title, which is simply a title or a name given to the current document. Since browsers have to inform the user about what they are looking at; the title is what the browser, shows at the top most position.

The title is one of the most important elements in a HTML document, based on the fact that if no title is defined, the user must rely on the HTTP Address URL to identify what document he/she's looking at.

The <NEXTID> tag was used in the elementary HTML versions and produced by the Next HTML editor to generate name attributes for Anchor tags. It's a long-deprecated tag and honestly I myself don’t perfectly know how it was used. 😅 It's not used anymore.

How can a deep understanding of HTML's development help you in developing modern web?

I can guess what you might be thinking by now: All we've learnt thus far, is how Markup languages have been developed and resulted in HTML's creation. But the facts about documents and their paper-like structures might seem irrelevant to how the web environment functions and looks nowadays.
But that's the trick about it. Nothing has really changed. Everything you see on the web, from the HTML5 games to the Progressive Web Apps to the smoothly maintained animations and SVG graphics, all this and more is built upon document structure concept. This concept is known as Document Object Model or DOM, which I will write about in the next part of this series.
I know reading this might seem boring and long and time consuming, but I can bet that by gathering this knowledge you can dive deeper into HTML5 Semantic Tags, Best CSS Layout Practices, SEO and How a Search Engine will treat and analyze your web application's <body> and <head>, JSX's data pipeline and how a Virtual DOM can become real and many more things.
Believe me, these are all based upon the simple Hypertext idea 😊.

Now that you're again full of energy and motivated to search for the deep roots of HTML, let's see what an HTML document BODY is.

This is how the <BODY> part is written in the example above:

<BODY>
  <H1>World Wide Web</H1>The WorldWideWeb (W3) is a wide-area<A NAME=0 HREF="WhatIs.html"> 
hypermedia</A>
  ...
  <DL>
    <DT><A NAME=44 HREF="../DataSources/Top.html">What's out there?</A>
    <DD> Pointers to the
    world's online information,<A NAME=45 HREF="../DataSources/bySubject/Overview.html"> 
    subjects</A>
    , <A NAME=z54 HREF="../DataSources/WWW/Servers.html">W3 servers</A>, etc.
    <DT><A NAME=46 HREF="Help.html">Help</A>
    <DD> on the browser you are using
    ...
  </DL>
</BODY>

What the body renders is a set of elements. Each element is identified by using tags. What text you put inside a tag is called its inner text and tags that you nest into it are called it’s children. The main tag itself is called the parent.
The inner text is the part which is printed in the browser page.

Question: But why should we use such sibling terms like children and parents for a HTML structure?
Answer: Because the HTML Document Structure behaves in an inheriting way.

The inheritance concept becomes more important when you need to handle layout, positioning and display. There's a good example in the above HTML markup which demonstrates how inheritance helps in layout designing.

The tag <DL> defines a Description List. What a Description List demonstrates is a list of items with each of them having a description of their own.

A good example for a Description List would be a dictionary. (click to read why)

A dictionary document contains a list of words. And each of the words has got a definition of itself.
The words are the items and the definitions are the description.

The above example uses <DL> to show a list of Hyperlinks. It can be said that each Hyperlink is written like a term, which in turn is defined with a description to tell the user about where the Hyperlink leads them to. This is the obvious purpose for the implementation of the DL in this document. But there's also another use for it...

It's layout. If you're already familiar with web design and CSS, you'd know how CSS properties like Flexbox or Grid help with the layout.
But the initial Hypertext project had defined no way of styling. And this was for good reason. Because Burners-lee anticipated the fact that HTML had to only contain document structure and markup, concluding that the styling logic shouldn't be implemented in HTML itself. This made HTML more flexible. One document structure could be styled in different ways, either by the user or the author or the browser.

What is Flexbox or Grid? Hell, what is CSS? (click to read if you don't know)
CSS stands for Cascading Style Sheets. A style sheet is a set of rules that apply styles to a document. And cascading means these rules act like cascades of water which override everything beneath themselves.
Thus certain style rules can be changed or overridden in certain parts of a document. This property is different from HTML's inheritance behavior and will be covered in future parts of this series.

Flexbox and Grid are some properties of CSS used for HTML layout. They align contents in a list-like and table-like way respectively.

What this means is that the description list element is used to give the printed (or the rendered) content some visual layout and structure.
The structure is implemented by showing only one Hyperlink on each line and it's description in the next line. This structure makes it easier for the reader to read the document.

I hope this example has demonstrated how the HTML documents were initially structured. Even the newest HTML versions follow many of these rules. So you can observe how and for what purposes HTML was developed.

And That's All For Now...!

We've come a long way, describing many things, that you may have already known.

But what I was trying to achieve by writing this long article, was to give you a fundamental sense of how the frontend technologies have been defined.
In my opinion, it's all based on the document structure, whether it's about online video meetings or social applications, or graphical animations.
Having a firm knowledge of the markup language and the inheritance methodology will surely help us throughout our journey to learn frontend deeply.
One important thing about the DOM is the usage of the semantic tags. You've seen different kinds of these tags in this article. They include title, h1, list and etc. Such tags are semantic in the sense that they let the browser know what role their content has in the document.
For example, a h1 tag means that its text is the most important title in the current document and surely its text contains some important and descriptive information about the current section.
Learning semantic tags is important for SEO, layout and even mastering the declarative and component-based programming. And in the latest definitions of HTML, newer semantic tags have been introduced which play a key role in developing better frontend applications.
In the upcoming parts we're going to use the knowledge gathered in this article to dive deeper into the sea of the frontend programming!

Feedbacks please!

This is a long post, and it took me a while to write it down. And since I'm planning to extend it into a series I would like to know your opinions and ideas about it.

And most important than all: Many things written in this post can be categorized as opiniated explanations. Therefore opposite or better explanations and theorizations might exist. If you have such ideas, please comment them.

In the next part we'll be back with the DOM.

Thanks for the reading! ❤️

Why I Succeeded In The Interview But Lost The Job!

MirAli Mobasheri — Mon, 04 Jan 2021 09:23:05 +0000

What did encourage me to write this post❓

Two weeks ago I applied for 3 companies. The job offers were aimed at junior Front-end developers. Well, all of them accepted my resume and two of them interviewed me. One of them never told the results and the last one offered me the job.

Yet I had to work for 3 experimental weeks and if they really liked the way I did my job, I would've been recruited.
So I accepted the deal and began to work there and then after spending a week on the job I got rejected. Certainly I was paid for the one week work but in the end, right now I'm sitting jobless in front of my laptop, trying to describe to you why I succeeded and then failed.

I've shared valuable advices with you in this post.
But first of all I suppose you need to have some background of me.

Who am I?

I am Ali and I'm a deaf. Deaf is the word that could describe me appropriately. Because it's not only a disability it's also a way of life.

I live in Tehran, Iran and I'm 21 years old. I'm still studying at the university. My education field is Industrial Safety and I'm currently studying at the Shahid Beheshti University of Tehran.

I think this short introduction is enough to let you have some basic knowledge of my condition.
Now let's have a few words about how I entered the world of code.

How the journey began...

It wasn't a stormy night in the middle of the winter. The journey had actually began since my youth. I am 21 years old at the moment and the first time I wrote my first line of HTML, there was no sign of it's fifth version.

And then the HTML 5 and the CSS 3 were introduced. The excitement at the time was mainly about the HTML semantic tags and the CSS opacity and border-radius properties. Since then the languages have developed further more.

And then I got lost in the journey...

Yes, I had written HTML a very long time ago. And I was even learning PHP 5 and MySQL. But it was never serious learning. It was out of curiosity and self-pleasure. So I left the learning hobby very soon in order to continue my school studies.

But a day came, when nothing was like before. My left ear too, said goodbye to the hearing world to join my right one; which had gone deaf since my childhood.

Who said there were no stormy nights?

Having a severe deafness, up to 90% in both ears, I was left in the world of solitude. Talking, socializing, learning and any normal activity that you could name, became tremendously hard for me.

But for the next three years I was the top student in a normal high school. I found my way into the university and then, finally I returned to my old hobby. Programming.

What is Bootstrap? Where did React.js come from? Really, ES6?

Being absent for a long time, I knew nothing of the newest developments in the frontend world. It was like I had come out of a cave in which I had lived for a thousand years.

Then I began to experiment with the new things and eventually I was on the road to become a front-end developer.

Apply here, apply there, apply everywhere

Three months have passed since the first time I really applied for a job. Then I had applied for 3 companies but none of them even accepted me. Why? you may ask, and my answer would be that my resume sucked.

It was just a description of myself and the things I liked and how I was involved into programming. Aside that I had an open source sample project on Github which was deployed online. But the project was unfinished and it really had no great design.

I had thought the code itself and the technologies that I had used in it would be enough. But it wasn't, so I didn't even get a call for an interview.

About two months passed, and I got my first interviews. How?

How I Succeeded In The Interview.

# Point 1: The resume, the resume, the resume.

I totally rewrote my resume. There were no descriptions of me. Just lists of what I had mastered and what I was currently learning and what I had had experience with. It went like this:

I know JavaScript since my youth. I'm mastered at: HTML5, CSS3, JS ES6, jQuery, Bootstrap, React.js, Redux.js, ...

I'm currently learning: Advanced Node.js, Express.js, ...

I have experience with: Python, Web-Scraping, Phaser.js 3, ...

Plus points:

Clean code

Functional Programming

High self-education and self-reliability: Top high school student, despite hearing problems

So as you can see, instead of writing sentences, describing myself, I gave quick facts about my abilities and specialties. This way the reader can quickly match my abilities with the requirements of the job.

But the resume's description part wasn't the only difference. I also created more sample projects.

# Point 2: Sample Projects, or Show Them What You Can Do.

The second time I sent my resumes, I had three main sample projects. Every three of them were big projects, but unfinished. But the point here isn't the project itself, or its deployment and demo.

What I did was to write proficient descriptions for every project in my Github account. In my resume I redirected the reviewer to the readme section of my repos and tried to attract their attention.

What my Readmes included were a list of descriptions of the technologies I had used and their purpose.
Such a description is what actually every reviewer is looking for. No one is going to review every line of your code.

The fact that you can explain the tools you have used in your project and their purpose, will give the reviewer a good idea of the fact that you generally understand those tools.

# Point 3: The Interview, or Let The Stress Out

Because of my deafness and due to the Covid-19 spread I offered both of the interviewers to do the interview on a video call and type the questions at the same time.

Since I couldn't hear their voice, they would type their questions for me and I would give my replies by speech.

The most important part about job interviews is preparation.
You should study the languages' and the libraries' references and have a good realization of their application. But...
Remember that in an interview you are actually compared to other appliers.

So you don't have to answer every question correctly. But answer every one of them with confidence. And if you don't know an answer, just confess it. Don't give random answers, as it would cause negative attention.

And remember that your interview also demonstrates how you can share knowledge and collaborate in a team. Therefore don't get stressful.

Thus there is no magic way to succeed in an interview, but the picture you give of yourself can ultimately lead to success. This can be achieved through a confident resume and interview.

Yes, I managed to succeed in one of the interviews which was more generally about the core JS, CSS and HTML.

I don't think my other interview was really very bad, but it was the kind of interview which required you to know every theoretical parts of React and Next.js or Node.js and etc. which I didn't really have a good grasp upon. I was never informed of the results.

Accepted but not recruited.

How I Failed The Job

The seventh night, after I returned from work, I received a text message which went on like:

Mr. Mobasheri, hello:
As was mentioned before in our skype chat, we always experiment our coworkers in an experimental duration. To be successful in our business we need an experienced and fast developer. But in the week that has passed we've concluded that we can't continue collaboration with you.
We wish you the best in the path you have chosen...

Well, there was nothing special I could do about it. But I thought it was my right to know why I was rejected.

"What's wrong with my work?", I asked the senior programmer the next day, "I have done everything you required of me!"
"What's wrong with your work?" He typed this on the WhatsApp web app, open on the screen in front of him (because of my hearing issue), "Let me tell you."

And I thank him for his clean and direct reply. I never knew how much wrong I had gone the way.

# Point 1: Clean Code, or You Don't Know JS

I was informed that writing messy code was my biggest issue. But wait. Hadn't I written in my resume that clean code was one of my plus points? So how comes that I couldn't follow its rules in my own code?

I had read the Clean Code book and have always tried to implement its rules in my programming. But it turns out that my problem was in React.

I didn't write clean React components.
I didn't use React's core abilities to shorten the code.
I had even written a long useEffect to manage routing states for a part of the site which used step by step navigation, while I could have achieved this using JS Objects.

But it wasn't only about React. In fact clean code isn't all about component names and Pure Functions. It's also about using the programming language's own methods to reduce code. At which I was again defeated.

There was a point at which I had to format Integers to prices. As an example: 25000 -> 25,000. Since the project was multilingual and both Persian and English formats of the price were required, I had chosen to write a complete function which would do the job. Using map and reduce and other array Methods, it consisted of 13 lines of code. But indeed I didn't need to use that. JavaScript has an in-built Method for Integers which is toLocaleString() and that does the job perfectly. The only thing I needed to do was to pass it the lang abbreviation (English: 'en', Persian: 'fa').

As simple as this I was rejected for not having a deep knowledge of everything about React and JS.

# Point 2: Responsive Design Strategies, or Understanding Every Bit Of HTML 5 and CSS 3

God, I know responsive design! I know how to implement Flexbox. Even when during the interview I was asked how to create a Glassmorphic design, I replied that backdrop-filter: blur is the right way and it was totally right.

But the senior programmer told me that I had used strange ways to implement design in the Front-end.

I had wrapped many elements inside a div tag. Instead I could use CSS properties directly on the elements themselves.
I had used the percentage unit % over and over again. I was told that the percentage unit isn't very predictable. And also that I had written rules like padding: 30% for responsivity, which he said he had never seen before.

But why did this happen?

The senior programmer who was also my interviewer told me that I had had the best interview results and that nobody had answered the questions as thoroughly as me, but he wondered why I wasn't so good in action.

I needed more experience and that was right.

But there was also another fact. He told me that the interview's questions were all the type of questions for which to be able to give a correct answer you had to have had some experience in the related matters.

Well that's truly right. I was experienced enough to answer all those questions. But the interview questions mainly focused on the general matters. I'm a self-educated programmer. I have practiced everything by myself. So I might have solved the problems in ways which didn't look standard or clean.

I have learnt the technologies widely, but not deeply. I can create a web app or a website from the scratch using the famous tools. But I'm not fast enough. That's because I haven't focused enough on the design patterns. I haven't learnt the languages and the libraries deep enough.
And most importantly I need to practice every small aspect of the technologies and the languages used in the Front-end development.

That's the goal I set for myself yesterday when I returned home from the office.

Got paid but failed:(

What To Expect In The Future?

I hope this post would be helpful for the readers.

But if you have really read through my long story, I would be glad to announce that I want to start publishing new series of articles on dev.to.

My goal is to write about clean code in React.js and deep learning of JS, HTML, CSS, React.js and etc.

The Journey Has Just began.

Failed but not done 😏