DEV Community: Chandelier Axel

Everything is a file in UNIX ?

Chandelier Axel — Sat, 11 Jun 2022 21:20:57 +0000

You most likely heard that everything in UNIX is a file, but it never really clicked for you. Or you get it, but couldn't find the technical details behind it. Or you have no clues about what this even means - like me before this.

In any cases, you are at the right place. Got your coffee ? ☕ Let's dive in.

Is everything really a file ?
What is a file, if everything is a file ?
Inode
- Basics
- Inode number
Directories
Data

Is everything really a file ?

Yup.

This yet simple but quite complex sentence resume the entire architecture of the UNIX Operating System (OS).

Basically, every features your OS is able to do, rely on files. Processes, devices (such as a printer, or your mouse), networks, and even directories.

Wait, directories ?

Yup. There are 7 different types of files, you can find a complete list here. For now, we'll focus on regular files, and directories.

What is a file, if everything is a file ?

From an OS point of view, a file is actually nothing more than a specific data structure called an inode. You may visualize an inode such as a table containaing file related informations.

The inode itself contain all the metadatas (extra datas that describes data) relatives to the file it describe. Informations such as the creation date, the last update date, the ownership, the permissions, the file size ...

⚠ The file name and the actual file data are not part of the inode, keep it in mind, we'll cover this later.

Inode

Basics

You can visualize an inode informations directly in your terminal, by typing the ls -l command.

Here's the kind of output you should receive :

-rw-r--r--  1 user  root  13 10 mai 22:10 index.txt

In order :

File type and permissions. It's quite hard to read, let's break it down together.
- The first character specify the what kind of file this is (the 7 types we mentionned earlier).
  - - Regular file.
  - d Directory.
  - l Symbolic link.
  - b Block special file.
  - c Character special file.
  - s Socket link.
  - p FIFO.
- The next three characters are related to the owner permissions for the file.
- The next three characters are related to the group permissions for the file.
- The last three characters are related to the others permissions for the file.
  
  All permissions fields can be read as follow :
  - Is the permission allowed to read the file ? - for no, r for yes.
  - Is the permission allowed to write the file ? - for no, w for yes.
  - Is the permission allowed to execute the file ? - for no, x for yes.
Number of hard links. You may find more informations here.
Owner name.
Group name.
Number of bytes in your file.
Date of last modification.
~~File name~~. Not a part of the inode, but still in the output. More on it later.

📌 You may find all these informations - and more, directly from your terminal in an UNIX environnement with the command man ls

If you're willing to get a bit more informations about a specific file, you may want to use the stat command directly.

Inode number

If you execute the ls -li command you will find an extra column at the beginning of the output.

12345678 -rw-r--r--  1 user  root  13 10 mai 22:10 index.txt

It contain a very specific integer, the inode number.

💡 This number is the unique identifier for this specific file in your entire file system.

Every files will have a different inode number (with the exception of hard links), and there's a maximum amount of inode number your file system can handle. Afterward, you will not be able to create anymore files.

File name and directories

If the filename is not specified by the inode, where is it stored ?

You most likely already guessed it by the title, but the file name is stored within the parent directory.

What exactly is a directory then ? It's actually a pretty simple thing. Type ls -l command somewhere with a directory.

drw-r--r--  1 user  root  13 10 mai 23:17 directoryName

Noticed the d at the beginning ?

The directories files actually only contain a mapping table, between a file inode number, and his name.

Inode number	File name
900	file.txt
901	data.json

The list goes on for all the file or other directories it may contain.

A directory is nothing but a specific file, it also have an inode number, and his name is saved within his parent directory inode.

📌 ls -li for a directory to see the inode number

899 drw-r--r--  1 user  root  13 10 mai 23:17 directoryName

Here's a complete representation of the content of a directory.

💡 The first two entries are references to itself, and to his parent directory.
📌 To see them, use the -a option on the ls command to see hidden files.

Inode number	File name
898	.
899	..
900	file.txt
901	data.json
902	newDirectory

The file data

So, where is the file data ?

What make the inode so special is that it kept references (pointers) toward the memory blocks that are actually containing the data in disk. By doing so, when we ask to open the file, it go through all of them and recover the informations needed.

The pointers part is oversimplified for the sake of this article, indirect pointers are purposely omitted.

Let's get a visual recap for a file inode.

File Inode
File types and permissions
Hard links
Owner name
Group name
Number of bytes
(A lot more metadata informations )
Pointer toward block n° 100
Pointer toward block n° 101

I hope you enjoyed the read, and learned as much as I did. If you have any questions or comments, feel free to reach to me on Twitter or in the comments below. Have a nice day !

Why do React need to be in scope for JSX ?

Chandelier Axel — Mon, 20 Sep 2021 20:00:07 +0000

`React must be in scope when using JSX`

Quite an annoying error, right ? What does it even mean anyway, you simply wrote a pretty basic component, and nothing happen but this error.

You don't know how to fix it ? Or you never bothered looking at why you need to do so ? Or maybe you heard that the versions 17+ of React dispense us from doing so, but still getting the error ?

You're at the right place, we'll go through the why, up to the how. Feel free to skip any part with the table of contents below.

Got your coffee ? ☕ Let's dive in.

Why are we getting this error ?
How to fix ?
React version 17 and beyond

Why are we getting this error ?

First, in order to understand why, you need to know how the JSX synthax work. For a complete breakdown, feel free to read this previous blog post that I wrote.

For a quick answer, let's analyse a React component :

<CustomButton color='red'>Click me !</CustomButton>

This example come directly from the React official documentation

When React receive this component, it basically transform into this :

React.createElement(CustomButton, { color: 'red' }, 'Click me !');

Because JSX is nothing but syntactic sugar for the createElement function, the code above will be called when creating our component.
But .. In the context of our file, we never imported React. What will happen ?

Exactly : React must be in scope when using JSX.

If we don't import it at the top of our file, the React.createElement would crash, as React would be undefined.

How to fix ?

As stated before, you need to import React within your file, in order for the script to resolve properly the createElement function. From here, you have multiple choices :

import React from 'react';
// or
import * as React from 'react';

Feel free to refer this Dan Abramov tweet for more informations.

At the end, it's up to your preferences, there's no immediate downsides using one or the other.

Wait, didn't you say that in version 17+ we don't need it anymore ? Indeed.

React version 17 and beyond

As of React v.17.0, we are now free from doing such import. If you want more informations, here's the link for the official release notes from the React team.

If you want the quick explanation, they added some code for compilers (such as Babel) to plug in, and add the import themselves when compiling our JSX. Hot stuff, right ?

But you might still get the error.

What ?

Yes, but it's not from React ! As we said before, most of the time, the projects use a linting tool such as Eslint, and some specific set of rules as been created for React. One of them enforce you to import React if it detect any JSX within the file.

If you're using React v.17.0 and beyond, you can freely disable the rules.

"react/jsx-uses-react": "off",
"react/react-in-jsx-scope": "off"

You can now remove all the

import React from 'react';

Before your finished your coffee, you learned why we needed to import React with JSX.
I hope you enjoyed the read, and learned as much as I did. If you have any questions or comments, feel free to reach to me on Twitter or in the comments below. Have a nice day !

How to handle your JWT in your applications ?

Chandelier Axel — Wed, 18 Aug 2021 19:19:25 +0000

This question is a sensitive subject all over the internet. Wherever you'll look at, peoples tend to be really dogmatic.

- Don't store it in Local Storage !!! Don't you know about XSS attacks ?!
- Please stop believing that storing your JWT in an HttpOnly cookie is secure........ You're still exposed to XSRF attacks.

You get the idea.

Long story short, I was looking for informations to build a robust authentication system myself. I did know nothing about the attacks quoted above, and of course, how to protect my application.

I'll do my best to summarize what I learnt, what are the different techniques and their fallbacks. This article will also try to be as opinion free as possible.

Without further ado, let's dive in.

What is the problem ?

Disclaimer: I'll purposely fly through what a JWT is, to focus on the security part. You may find information on their dedicated website.

Because there's one.

Let's assume that you're building a new website, and you're on the authentication part. After some research, you find out that the go-to (as time of writing this) is using a JWT, a Json Web Token.

A JWT is basically an encoded string that will contain some basic informations (anything you want). Your server will send it back to you when you'll do your login process, and your client will need to supply it on any further requests where authentication is needed in order to be accepted by the server.
In short, a JWT is a way to identify your user as a legitimate and authenticated one towards your server.

So .. If we need to supply the JWT on any further request that need authentication, where do we tore it ?

This is where things get interesting.

Local Storage

My first idea, like a lot of people I believe, was to store my newly obtained JWT in the browser Local Storage. Things would be as simple as :

localStorage.setItem('jwt', jwtYouReceive);

And whenever we need it back :

localStorage.getItem('jwt');

Despite beign the easiest way to store our JWT, it turns out that this is, by far, the most insecure way.
By nature, everything stored within the localStorage is accessible through Javascript code. It means that, if somehow a hacker could execute some JS code in our website, he could steal the JWT, and any of his requests would be accepted as an authenticated user. A way to do so is through an XSS attack.

XSS Attack

Cross Site Scripting

Basically, an XSS attack happen when some undesirable code is being executed within your website. This can be as gentle as a console.log, but could go as far as stealing informations, our JWT for example.

Let's just take a very contrived example to understand it better.

Pretty simple, right ? Now here's the catch, what is sent through the form is not being sanitized (meaning any unsecured or unrelated part of the data is removed or escaped), and so an hacker could insert a harmful script.

<div>
    I juste created an amazing blog post !! 
    <script>functionToReadYourJWTandSendItToMe()</script> 
    Please, accept it !
</div>

This get inserted into the database, and when the admin open is page to see the preview of the blog post, the script will be hidden and being executed, succesfully stealing the admin JWT !

And if the admin accept the blog post, and it get displayed on the website homepage, the script will execute for every visitor that will open the page .. Stealing everyone JWT !

Here's a recap :

Storing the JWT in localStorage without the proper defences against XSS can be dramatic, this left the hacker with a potential large area of actions all over your website to try to find a breach.
The developpers now have the responsability to check for every possible breach and be mindful when developing new features.

There are ways to secure our app to XSS, such as sanitizing everything that would go into the database.

An easy to implement, but somewhat risky solution.

Second solution.

HttpOnly Cookie

While digging further in order to find informations about localStorage, I've seen a lot of peoples recommending to store the JWT into an HttpOnly Cookie. If you're not confident what a cookie is, feel free to go to the MDN documentation.

Be mindful that the HttpOnly part is the most important one. A cookie without the HttpOnly attribute could be read by some JS code, sending us back to the XSS problem.

By applying the attribute, we restrict the use of this cookie for HTTP requests only, securing us completely from XSS.

But .. We're now prone to XSRF attacks.

XSRF Attack

Cross Site Request Forgery

As the name may imply, the goal of this attack is to create a request on a malicious website to be executed on the targeted website. Let's take a real world example to understand it better.

You have your website open and you're logged in. Your JWT is securely stored into an HttpOnly cookie, meaning that every request you send to your server will automatically include the cookie, and so your JWT.

As every application with a user account, you have the possibility to change some informations by filling a form. This will send to your server a request, it'll verify your JWT, and allow the changes.

As you navigate to it, you received an email. You open a new tab, open the email and click on the link.

☠️ The website you lend on have a script that execute as soon as you open the page. Prepared in advance, it execute a request on your website. ☠️
How ? Well, the hacker could have created an account, open the dev tools and saw what was the endpoint to your server.

Basically the hacker send the same request as you would done, but he control the informations. Your username has been changed, your profile picture aswell .. Maybe even your password.

The most amazing part about this attack is that the hacker doesn't have to recover the JWT, it's automatically included within the HTTP request.

There are ways to secure your website from such attacks, which we won't cover here, but most of them tend to be prone to .. XSS.

Third solution.

Storing it into memory

Maybe even a simplier solution than localStorage, the goal is fairly simple. You attribute the JWT to a variable, and make it available for your needs.

const jwt = ...;

This variable is impossible to reach for a hacker, neither from an XSS or XSRF attacks.

Such a simple solution as one serious downside : whenever your user will close your website, the next time he'll come back, he'll need to login again, creating a very poor user experience.

Just like the other solutions, there are ways to mitigate the downsides.

Having a refresh_token

When you request your initial JWT, the plan is to get an extra token, a refresh_token token (which is basically a JWT that will live longer). This token will be saved in the browser within an HttpOnly cookie, aswell as on the server within a database. His goal is to keep the user login without him having to go through the login process everytime your JWT expire, such a process is called a silent refresh.

We can actually use this behavior to pretend the user session is being persisted. As the refresh_token is stored within the cookies, we can use it across sessions. When our website boot-up, we will trigger a call to a particular endpoint, this endpoint will return a JWT only if the refresh_token is still valid.

- How is this secure if the refresh_token is a JWT too ?
The refresh_token will only be used and accepted in the particular endpoint that is dedicated to him. Trying to access the rest of the API with it will fail.

- But a hacker could use a XSRF, right ?
Yes but he won't be able to see the JWT that is returned.

This method leads to a lot of boilerplate and overhead.

Wrapping up

None of the solutions above are bullet-proof, there's always a way for a brilliant attacker to get in. Some solutions are easier to implement, some require more setup but offer an arguably better overall "protection".

Pick what suit you the best.

I hope it helped you to understand this incredibly dense topic as much as I did writing this.

You can find the original article on the Othrys website and you can follow my Twitter or tag me here to discuss about this article.

Javascript Modules

Chandelier Axel — Sat, 17 Jul 2021 21:42:06 +0000

Whats is a module ?

Basically modules are pieces of code that can be imported anywhere in your application. A module is really easily recognizable, as soon as you see the import or export keyword, you're dealing with a module.

So... pretty much everything is a module ?
What about the require keyword I've seen here and here ?
How do I use them ?

We'll cover everything from this point onward.

Grab a coffee, and let's get started.

A bit of history

As we can't really understand something without the knowledge of why it exist, we'll take a quick historical detour.

Waaaaay back in the days, nothing known as modules existed. But also, Javascript wasn't as widely used as it is today, it's only purpose was pretty much to add interactivity on your website.
Time goes on, and the use-cases grown as well. Javascript is more and more used, up to a point where JS was well-know for his monstruous single page codebase.

And nobody like 2000 lines long of code within a single file, right ?

So we needed a way to be able to split our code for obvious reasons.

Modules were born.

AMD, CommonJS, UMD

Unfortunaly, no specifications managed to solve this problem, so the community started to build tools that would solve the problem.

This is what AMD, Common JS and UMD are, tools to enable modularization within our projects.

From this point onward, we were able to do this :

// multiply.js
function multiply(a, b) {
    return a * b;
};

module.exports = multiply;

// index.js
var multiply = require('./multiply.js'); // Relative path to the file

var result = multiply(10, 10); // 100

We're now able to get the multiply function from any file by adding the correct require at the top level of your file.

2000 lines long files era is over !

ES6, export and import

Up to the ES6 release in 2015, we had to use such tools to split our codes and using modules. Now we got a standardized syntax and now work without such tools !

If we take back our previous example, this how it look like now :

// multiply.js
export function multiply(a, b) {
    return a * b;
};

// index.js
import { multiply } from './multiply.js' // Relative path to the file

const result = multiply(10, 10); // ES6 is here, we can now use const keyword 😉

Welcome to the present, let's dive straight into the ES6 modules !

Basics

I'll take functions as exemples because they are, in my opinion, the easiest way to understand modules. But you can do the exacte same behavior with all JS data types such as objects, arrays, etc.

Named exports/imports

You can either export this way :

export function multiply(a, b) {
    return a * b;
};

OR this way :

function multiply() { ... };

export { multiply };

Both are actually working and complety valid, they actually are doing the exact same thing. So what's the difference ? Well, let's say we have multiples things that we want to export, we can either add export in front of every functions ...

export function a() {...};
export function b() {...};
export function c() {...};
export function d() {...};

OR we could group all the export in one place :

function a() {...};
function b() {...};
function c() {...};
function d() {...};

export { a, b, c, d };

Let's now use our functions in a different file :

import { a, b, c, d } from './multiply.js';

Be very careful, the names of the values within the brackets must be the same as the exported ones

import { foo } from './multiply.js'; //<--- Will fail because there's nothing named 'foo' exported from the file

IMPORTANT NOTES

Exporting this way will give you references to the exported things, meaning that every modification on the value, will have an impact on all your imports.

Quick example :

const foo = {
    bar: true
};

// After 10 ms, we change the value of bar
setTimeout(() => {
    foo.bar = false;
}, 10);

export { foo };

import { foo } from './foo.js'

console.log(foo); // <--- { bar: false }

But what if the modification was caused by a function into a specific workflow ? You now have a global mutation, and lost track of the value of your object within your application. It may cause crashes and such terrible headaches debugging.

Default exports/imports

function multiply () {...};

export { multiply as default };

Adding the as default allow you to do the following :

import multiply from './multiply.js'; // <-- You're now free to remove the brackets

Oh, wait, before we move on, let's use the shortcut synthax for the export :

function multiply () {...};

export default multiply ;

export default function multiply () {...};

Using a default exports has multiples consequences :

It no longer export a reference but a value, it may be changed witout impacts on other imports

You are free to name your imports variable however you want, it's no longer binded to the exported names

import foo from './multiply.js'; // <-- You're still getting the multiply function, but it's renamed

You can only do ONE default export per module

IMPORTANT NOTES

There's actually a difference between

export { multiply as default };

and

export multiply as default;

But this is way past the goal of this article. Besides, Jake Archibald did an amazing blog post that you can found here that fully cover the subject.

Fancy but useful features

We covered the basics to get you started with the modules in JS, but there's some more syntax to know about imports/exports !

Mixing named and default exports/imports

//multiply.js
function multiply () {...};
function a() {...}

export { a };
export default multiply;

//index.js
import multiply, { a } from './multiply.js'; // <-- Work like a charm

Renaming

You're free to rename you imports/exports within the declaration :

// multiply.js
export { multiply as foo };

// index.js
import { foo } from './multiply.js'; // <-- Will give you the multiply function

foo();

// multiply.js
export { multiply };

// index.js
import { multiply as foo } from './multiply.js'; 

foo();

This came become handy in case you have name conflicts.

Import everything at once

Let's say you have a pretty big list of exported things :

function a() {...};
function b() {...};
function c() {...};
function d() {...};

export { a, b, c, d };

Instead of importing them all one by one :

import { a, b, c, d } from './foo.js';

You're allowed to do this :

import * as whateverYouLike from './foo.js';

whateverYouLike.a();
whateverYouLike.b();
...

We'll wrap up here, I hope you enjoyed and learnt has much as I did writing this, feel free to reach me to discuss about it or if any mistakes were made.

You can find the original article on the Othrys website and you can follow my Twitter or tag me here to discuss about this article.

Using await in loop cause performance issues

Chandelier Axel — Tue, 18 May 2021 18:14:36 +0000

Recently, I learned the hard way that await is not the solution to every promises.

At work, I had to write a piece of code that was looping for a lots of elements.

Bascially, it was looping over hundreds of elements, and was doing an HTTP request for each in order to retrieve some vitals informations.

It was something like that :

  //...
 const datas = [];

  for (const element of elements) {
    const result = await axios.get('https://pokeapi.co/api/v2/pokemon/ditto');
    datas.push(result);
  }
  // Use datas ...

This is a really simplified exemple using a free Pokemon API (We all have our favorite API's 🙈).
I didn't notice myself that it was causing a performance issue, it first came as an Eslint error :

    Unexpected `await` inside a loop.

🤔🤔🤔

It was time to dig and to follow the documentation link.

And just to make sure Eslint wasn't lying to me (You should trust him 100%), I did some testings ...

The test

Going back to our previous exemple, but with some console.time to evaluate the actual time it take for our loop.

const axios = require('axios');
const elements = new Array(45);

async function fetchPokemons() {
  const datas = [];

  console.time('Wrong way');
  for (const element of elements) {
    const result = await axios.get('https://pokeapi.co/api/v2/pokemon/ditto');
    datas.push(result);
  }

  console.timeEnd('Wrong way');

}

fetchPokemons();

Here is the Node code sample I used, feel free to try it out yourself.

It would be painful to make you guess how much time it took for our loop to finish, so here you go :

Between 12 and 13 seconds.

    Wrong way: 13.191s

Doesn't sound that bad for 45 HTTP calls, but let's see how it goes if we refactor as Eslint told us.

The refactor

async function fetchPokemons() {
  const promises = [];

  console.time('Nice way');

  for (const element of elements) {
    const result = axios.get('https://pokeapi.co/api/v2/pokemon/ditto');
    promises.push(result);
  }

  const results = await Promise.all(promises);
  const actualDatas = results.map((result) => result.data); // We need an extra loop to extract the data, and not having the requests stuff

  console.timeEnd('Nice way');
}

fetchPokemons();

So ... What happened ?

Well, we basically removed the await, and pushed all our unresolved promises into an array. Then we simply await for all of them to resolved, and we extract the datas.

Isn't it the same thing ?

Well .. Not really. Before we dive into the explanation, could you take a quick guess on how much time it take for us to gather all the datas ?

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Between 0.8 and 1.5 seconds.

    Nice way: 1.448s

🤯

Did we just cut down the time by 10 ? Yes.

Explanation

It's pretty simple, previously we were waiting for each requests to resolve before launching the next one :

Launch first
Wait N seconds until it resolved
Launch seconds
Wait N seconds until it resolved
...

Time add up a lot as we saw.

Now, it look like this :

Launch first
Launch second
...
Wait for what's left to resolve

You got it ? By the time we were looping and launching everything, some - if not most, promises have already resolved !

Conclusion

Now you'll think twice before awaiting in a loop.

If you are a bit lost and don't really get what was happening here, I wrote an article that cover all the Promises basics for Javascript.

You can find the original article on the Othrys website and you can follow my Twitter or tag me here to discuss about this article.

A complete introduction to Docker

Chandelier Axel — Tue, 27 Apr 2021 19:51:07 +0000

You saw that icon with a blue whale being compared to a cargo ship ? I'll assume in this article that it's probably as meaningless to you, as it was to me.

If you're like me, and heard of Docker for quite a long time now without knowing what it does, stay here we'll cover everything you need to get you started.

Introduction

First of all, let's start with the basics. To understand what is Docker and why Docker, we need a basic understanding how Virtual Machines works. To keep it simple, how is organized the thing that is keeping the websites alive ?

VM (Virtual Machine)

Disclaimer : I'll assume that you had little to no experiences with VM's, feel free to skip this part.

The theory

You finally ended to develop your amazing application, you got all the needs covered, all your tests are green and your client (maybe it's yourself ?) is satisfied. It's now time to launch your application to the public.

As you developped your product on a computer, you need a computer that can keep your application alive 24/7, right ? Here's the part were you need to host your application on a server.

A server is basically a physical big piece of hardware with all the components for the CPU, RAM, etc needed. On this server, supplied by the service provider you choose, they'll boot up severals Virtual Machines including the one you decided to paid for.

The hotel comparison

To represent it easily, I like to compare with an hotel.

This hotel is well-knowned for his themes based rooms (jungle, fairy, and so on).

When the hotel was built, someone was choosen to manage everything, the ressources, the peoples that work here, the reservations etc. Let's call him/her the Hypervisor.

As soon as someone want to book a room, the Hypervisor will take the call and make it happen. You want a medium size room with a jungle theme ? No problem. A small one with a fairy universe for a children ? No problem. He'll allow the specific ressources from the hotel for your desires.

This is exactly what's happening within a server. It possess an Hypervisor that will launch several Virtual Machines with specific configuration when needed. A medium room with the jungle theme is actually a Virtual Machine with an i5, 8GB RAM with a Linux OS.

If you have been in the industry long enough, you would remember that back in the days, we had to pay for an entire server for ourselves, leading to a higher cost. We couldn't just get a piece of the server for our needs. To put that into the hotel comparison, we had to book the entire hotel even if we only needed one room.

Basically, VM's allow us to transform one server, into multiples servers. A single room hotel, from an hotel with multiples rooms.

All hail to virtualization, right ?

The downsides

Despite being a revolution compared to what we were doing before, the virtualization of the machines have a few downsides :

They are slow to boot because of the entire Operating System they are carrying and need to install from scratch.
They are heavy, for the same reason explained above. They can take up to 10 GB.
Your application is bound to one OS, or you'll need multiples VM's. Imagine your application is divided into multiple services that have different requierements. You will most likely end into compatibilitiy issues. To solve that, you would have to either find a version that work for all, or boot another VM's with a different OS version and start the needed service here.

How Docker solve this ?

Docker enable you to pack your application into what they call a container. But, what is a container ?

A container is basically a lightweight, fast and portable piece of software. You can imagine it like a sealed bottle with a ship inside. No matter where you put it, no matter when, it's always gonna have the same look ... as long as it's not upside-down.

We'll jump in the creation of the containers later, for now let's focus on the general comprehension.

Alright, containers seems to be cool, but why use them ? Why Docker ?

Well, as we saw earlier, VM's are very heavy, they take a lot of time to boot up because they need to install their own Kernel and OS. In our hotel example, it could be translated this way : You booked a new room ? Alright we'll gather everyone and build this one as you desire. This includes peoples, materials, electricity, water .. And so on.

This is where Docker come in action. Instead of saying "Build everything !", Docker will come, kick off the Hypervisor and say "Alright, they want a jungle based room ? Let's juste take the premade we have here, clone it and put it in place".

Seems magical, right ? As you could have guessed, unlike VM's you do not need an Hypervisor when using Docker. You'll basically have a server, with Linux (or any others, really) based system, install Docker on it and boot up as many rooms as you want .. The rooms being the famous containers.

Why are they so lightweight ? Because all the containers will share the same underline kernel, unlike VM's that need one kernel each times. This is litteraly gamebreaker and allow them be started within seconds, literally. The downside of sharing the same kernel is that you can only boot up Linux containers on a Linux based system, and only Windows containers on a Windows based system.

Docker basics

The containers

As we saw before, containers are basically the bread and butter of Docker, they insure your app into a very isolated system with it's very specific needs.

How are they created ? How do I start a Docker container ?

First, you need an image. We'll explain what an image is and how to create one later. For now, all you need to know is that an image is pretty much the mould that you'll use for your container.

For now, we'll use already created images. Most of the biggest technologies hanging around have their official images, such as NodeJS, Postgree, MongoDB, Redis .. And so on. You can find all of them on the official Docker website : Docker Hub.

Let's play around with one of them.

First, let's download the image, your mould :

docker pull hello-world

This command will go straight to Docker Hub and get the latest version available. Once it's downloaded, the image will be avaiblable on your computer as long as you don't delete it. (More on the images on the next chapter)

Now that you got it, time to do something with it, right ? Let's create our first container :

docker run hello-world

You should see a text appearing in your console, congratulation, everything is working !

To see all your containers, you can type :

docker container ls -a

The command will gather all the informations you need :

The container ID (really useful when you want to manipulate a specific container).
His name (randomly generated by Docker, or you can choose your own).
How much time passed since it's creation.

And way more !

This was a very basic example, the container is pretty much doing nothing. The purpose was to give you a quick insight on how we create containers.

For a more concrete exemple with a MongoDB database, I would recommend you this official tutorial by the Docker team.

The images

We just created a container, based on an image. What is an image then ?

Well, it's pretty easy. An image is a mould, a description, a package with instructions on how
to create containers. They are created from a .dockerfile with a set of instructions on how to be built.

You can create your own image based on another one, everything is possible. You want to add a custom software on a Linux distribution ? Just get the image, write your .dockerfile and publish it on the Docker hub so everyone can get it !

That's all, really.

I hope you enjoyed this quick introduction into the Docker world. This was a very high-level overview, this is a very complex and a whole ecosystem in itself, there's plenty more to discover !

You can find the original article on the Othrys website and you can follow my Twitter or tag me here to discuss about this article.

My experience from bootcamper to freelancer.

Chandelier Axel — Tue, 02 Mar 2021 14:11:13 +0000

Today's article will be a bit different, I would like to retire from the code itself for a moment, and talk about my early developer experience. I have a feeling that people who started their career very recently might find this article helpful.

I'll try to gather what were the most useful skills and things I've accomplished that allowed me to find my first job as developer, 2 months after a bootcamp, and then become a freelance.

My journey
Personnal projects
Tutorials
Documentations
Ask questions
Share success
Group activities
Be focused
Learn tests
Tech challenges
Teach

My journey

My coding journey started in a bootcamp in 2019, it was an intense 5 months of learning pretty much everything I needed to be a ~~successful~~ developer.
I had never touched nor seen an HTML tag whatsoever, but I had a feeling I would love it. I had no background in tech, no engineer degree and had nobody that could help or teach me.

To give you an idea of what the program was, we had 5 months to learn the basics of : HTML, CSS (some CSS framework too, like Bootstrap), JS, React, Node and SQL.

Needless to say it was a tough rush.

Needless to say, if I had only been following the program without investigating and working on the side, I wouldn't have been able to find any job afterward (not that quickly, at least).

I knew that we (my coworkers and I) would all have the same knowledge, and pretty much the same background in the end. It was a necessity to step out to be the chosen one.

I had to level up faster.

Now, I've created my own company, Othrys with my partner Ferrand Gaël. We're working as freelancers with companies such as AirBnB and the french store chain Monoprix.

I'll go through what helped me. It might, and probably will, be different for you. Keep in mind that the goal is to help people that are learning. If you have any extra recommendations, leave it as a comment, I would be very happy editing the article and crediting you for it.

Make personal projects

This is the most time-efficient thing you could ever do. Take a subject you haven't really understood yet, and build something with it. You'll stumble, but you'll learn a lot from it. And this is something you'll be able to show to a potential recruiter to show your determination and what you can do. It will also give you confidence into your skills, and allow you to measure your progression when you go back into old projects.

If you're wondering what to build, there are plenty of possibilities. Take a topic you love : a book, a video game, a movie, a sport, and make something you wish already existed, or build it better. Or find a very well done website, and try to mimic it.

If you're really out of ideas, I would suggest you this article wrote by Unnati Bamania that gathers a lot of possibilities.

I personnaly created a competition system for one of my favorite video games using React, Node and an SQL database during my bootcamp. It took me a looong time, but I knew it could be useful as a proof of my abilities.

Stop following tutorials blindfolded

Instead of spending time copy/pasting a tutorial, try to find the solution by yourself. Doing so, you'll get a deeper understanding on what you're working on, and you'll be more prone to doing it again.

If you're building something new, go read the documentation, it should be good enough to get you started with the basics.

Don't get me wrong, I'm not saying to never read any tutorial. Some are very well done and well explained. If you're following one, you should focus on the explanations instead of stopping to the code samples and wondering why it's not working.

We all copy pasted that weird Stack Overflow function that does some unknow magic.
It's working ... Right ?

## Read the documentations

If you're digging through a tutorial, you might land on the documentation page of the technology you're using.

Read it.

Especially when you're learning everything at once or in short period of time, it'll help wrapping your mind around the why. It might be boring, and you will understand only a very tiny part from it at the beginning, but believe me, it'll pay off big time.

Ask dumb questions

If you keep reading resources here and here, you'll necessarily ask yourself questions.

Ask them.

This is the only way to know for sure if you understood correctly. It might even be the genius moment when you ask the question, and everything becomes much more clear as soon as your formulate it.

If you are lacking on people to reach, try social medias. Most of the developers I know are always happy to share a bit of time or knowledge with you. If not, they might even ask someone they know to help you out !

Don't get discouraged if they don't, building a community take times.

As a last resort, Google might be able to link to very good resources that could help you !

If you have specific code questions, you could even try to post on Stack Overflow.

Share your success

You should always be proud of what you accomplished, especially when you were stuck for hours/days on the problem. Other people will always be super happy to celebrate with you, they could also learn from your struggle, killing two birds with one stone.

The same peoples that you'll be celebrating with, will cheer you up when that impostor syndrom will kick your ass off.

I would suggest you this podcast from Kent C Doods that cover this subject from his point of view.

Prioritize group activities

The time where a developer was that nerd boy deep down its basement is over, sorry. In every single company you'll be working in, you'll always be working with other people. You must be able to cooperate with a group of people, to share your ideas with them, to ask questions when you need to or even to give some advice !

Be focused

There's a ton of things to discover and learn. It can be mindblowing, and if you are like me, you'll want to know eveything ... It's impossible and I consider this as a bad practice for beginners : You'll necessarily end up to know a tiny bit of everything and never be good enough at something in particular.

Not exactly something very valuable when looking for your first job, right ?

Learn how to write tests

Tests are the best way to ensure code quality, to chase bugs and make sure they'll never come back. A 100% tested application doesn't mean a bug-free one, but you'll know for sure that the bug you fixed a week ago will never come back.

There's a whole subject about testing in general, this is an entire world with a tons of tools. It can be tricky aswell, but it will pay off big times when looking for a job.

Don't be affraid to accept technical challenges

If you're feeling it, you should volunteered to take a task you know very little about. Taking a subject you know very little to nothing about is one of the best way to progress.

In my previous job, I personnaly had to learn Apollo, GraphQL and Typescript on the fly for a mission I was assigned. I'm not gonna lie, it was hard and that impostor syndrom kicked my ass off. It took weeks before I became confident with the techonologies and finally considered myself as a real developper for the mission.

Teach

The only way to know for sure that you'll understand a topic, is to teach it to someone. If you can explain clearly a subject to someone else, you can be confident into your knowledge. Of course don't fool yourself and work on the subject before explaining.

Another way to do so would be to write articles. You don't necessarily need to publish them, but the writing process will help you to discover where you knowledge is lacking.

This is personnlay my favorite, I wrote one for NPM and one for Javascript promises in my process of relearning the basics.

I hope you enjoyed the read, and if you made it that far, thank you !

You can find the original article on the Othrys website and you can follow my Twitter or tag me here to discuss about this article.

The Promises guide I would have loved as a junior developper

Chandelier Axel — Tue, 09 Feb 2021 17:29:37 +0000

Do you remember stumbling on your first "Promise {pending}" ? Putting a .then just to see if it magically work ? This article is made for you, after our last article about NPM, I'll take you with me in my process of re-learning the basics bricks of the JS ecosystem.

The scope of this article is basically from understanding Promises, (how to write and recognize them), to an async/await dive. Fell free to skip to any parts with the table of contents below.

Disclaimer : We won't see the 'hidden' part of Promises. By hidden, I mean how the Javascript engine handle them inside the call stack.

Necessary background informations
- So, what are Promises ?
- Why do we need them ?
Let's dig into the code
- How can I use them ?
- How can I recognize a Promise I didn't write ?
Some additionnal informations
- Async / Await

Necessary background informations

The MDN web documentation definition for promises is the following :
A Promise is a proxy for a value not necessarily known when the promise is created.
It allows you to associate handlers with an asynchronous action's eventual success value or failure reason

If it's unclear to you as it is for me, stay with me, we'll clear everything up, I promise 😉.

So, what are Promises ?

Now that we let this bad joke behind, let's dive straigt into it.

First, the basics. Javascript is a synchronous and mono-threaded language. It means that all your code will execute in the order it's write, and it only has one call stack. To keep it simple, we'll stand that JS is a language where eveything happen in order, without any external add-ons.

Promises are a way to execute certain pieces of code asynchronously, meaning they'll be executed behind the scenes, while the rest of the synchronous code is done.

Why do we need them ?

Let's take a real life exemple with two waiters. To keep it simple, our waiters are responsible from taking the orders, and delivering the dishes froms the kitchen to the clients.

Our first waiter will be the synchronous one (like if Javascript promises never existed). He would take the order, give it to the kitchen, wait for the dishes to be ready, and finally serve them, and so on. Kinda awkward and inefficient.

Our second waiter will handle things asynchronously. He'll take the orders from the clients and give it to the kitchen. By the time the dishes are ready, he will go do something else and come back later for the dishes whenever they are ready.

This is exactly what's happening in JS. The kitchen will give a promise to the waiter that the dishes will be ready sometime in the future.

If promises never existed, all our code that requires an external HTTP call will block the rest from executing until the call is over, just like our first waiter was stuck at the kitchen in between orders.

Concretely, on a website, you couldn't see the text or the shape until everyting has been loaded, leading to enormous loading time, or weird-looking pages. And nowadays, nobody want to wait more than 2 or 3 seconds for a website to load, right ?

Let's dig into the code

How can I use them ?

Now, let's write our first Promise. A very basic one would look like this :

new Promise((resolve, reject) => {
  // Your asynchronous code
});

A promise always take a function with two arguments : resolve and reject. When the promise must return the result, we call resolve with the results. If something wrong happened, let's say we're missing some ingredients, the whole promise is compromised, we must cancel the order and get something different from the client, this is where we call reject.

// Your promise can be stored in a variable, or returned within a function
const preparingDishes = new Promise((resolve, reject) => {
  const isIngredientMissing = false;

  const dishes = [
    // Everything that the client ordered, it would be filled up as soon as one is ready
  ];

  // But if an ingredient is missing, immedialty call back the waiter to inform the clients
  if (isIngredientMissing) return reject('An ingredient is missing !');

  // We use setTimeout to mimic an HTTP call
  setTimeout(() => {
    // 10 seconds later, once the dishes are ready, send them to the waiter
    return resolve(dishes);
  }, 10000);
});

Now, what is the value of preparingDishes ?

console.log(preparingDishes); // <---- What will appear in the console ?

If you're already familiar with promises, you answered "Promise {pending}" and you're right.
If you were expecting [ ] don't worry, we'll figure this out.

console.log(preparingDishes); // <---- Promise {pending}

Why ? If we keep with our waiter exemple, we say to the kitchen : Hey, I have a new order, prepare it, and we didn't let the necessary preparation time, so the kitchen answer It's not ready ! We're still preparing it. The promise is pending.

How do we access the value then ?

Do you remember the MDN definition ? It allows you to associate handlers, the keywords here is handlers. Let's go back to our previous exemple, but let's get it to work for real this time.

const preparingDishes = new Promise((resolve, reject) => {
  // See the code above
});

// Now that our promise is created, let's trigger it, and then read the results
preparingDishes
  .then((dishes) => {
    // dishes is a arbitrary name, usually it's called result

    /* Within this function, we can access the result of the promise. The parameter will be the value you gave to the resolve.
    You are guaranted that anything you put in here, will execute when the promise is fullfilled (succesfull) */
    callWaiter(dishes);
  })
  .catch((error) => {
    // In case an error happened, this handler will catch the return value inside your above reject or any error that could happen in your promise code
    if (error === 'An ingredient is missing !') {
      sendWaiterBacktoClients();
    }
  })
  .finally(() => {
    // This one will execute anything that you put inside, either the promise succeed or not

    // For example, wether the kitchen succeed preparing the dishes or not, they'll have to start the next one
    prepareNextDishes();
  });

As you must have noticed by now, the .then, .catch and .finally are the handlers MDN is talking about. Each will execute under different circumstances as stated above.
Please take note that attaching all the handlers isn't mandatory, you could only attach a .then for exemple (but I wouldn't recommended it), or only a .then and a .catch, which is what you'll use most of the time.

Nice ! Now that we write our first promise, and used it properly, let's go to the last part, where I personnaly struggled a lot with.

How can I recognize a Promise I didn't write ?

Let's say you're onboarding on a new project, you must get used to the codebase, but you're not sure what is asynchronous or not. Or even better, you're trying to figure out how to use a thrid-party library without the documentation.

You have 2 solutions to figure if a specific piece of code is a promise or not.

If you're using VSC as your text editor, you can let your mouse over the piece of code you're interested in. In the pop-up that's appearing, you can analyse what is the value. If this is a promise, you will see it as :

  Promise<any>

Don't let the 'any' keyword instill doubt, this is some fancy Typescript, and will be replace with any value the promise is returning.

If a .then is hanging around, the variable before it is 100% a promise (unless the code you're stepping in is already broke 😕).

Additional informations

As we saw it, a promise is always followed by specific handlers. They are all meant to be used with promises, using them with a string for example will lead to errors where JS will complain that .then is not a function.

Even if promises are very cool, nesting promises in promises can lead to what we call the callback hell. Imagine that a specific piece of code result from a serie of promises, you'll have to wait the previous promises to be completed to access the value, and so on, leading to scary things like this :

gettingOrder.then((order) => {
  giveOrderToKitchen(order).then((dishes) => {
    serveClient(dishes).then(() => {
      startOver();
    });
  });
});

I purposely omitted all the .catch here, the readability already took a shoot. To solve this, we do have a powerful tool, async/await.

Async / Await

First, I would like to clarify something that took me a long time to understand, async/await is nothing more than syntactic sugar for promises.

Let's rewrite our first promise :

// Your function must be async to use the await keyword
async function waiterJob() {
  try {
    const dishes = await preparingDishes;
  } catch (error) {
    // Handle the error
  }
}

So, couple things changed here, we now have a function with the keyword async, a try/catch block, and the await keyword. Even if we still don't get what happened here yet, we can already say that it's way cleaner.

Here are the rules for using async/await :

The await keyword can only be used within an async function.
- It replace the .then, you must not use it in conjuncution with .then/.catch. Exemple :

  // ☠️ Don't
  await preparingDishes.then((dishes) => {});

  // Don't do this kind of no sense either, it would work, but it's way more readable as a full async/await
  preparingDishes.then(async (dishes) => {
    await something();
  });

Making a function async will enforce it's return value to be a promise. In our exemple the waiterJob function is a promise that you'll have to await aswell when calling it.
Using await is a bit more tricky than the .then. If you want, you could await in front of a string, JS won't complain unlike the .then. Be very careful of not using it everywhere.
- Using await where you don't need to won't lead to bug in itself, but the async function around it can, because it can break you app if you don't handle it properly.
To handle errors properly, you must wrap your promise call within a try/catch block. Our previous .catch will be handled here, and anything that break inside the try will be caught.

Hold on a second, you said that all async function must be awaited ? This is endless !

Well, not really. Most of the time in your real apps, you'll have a synchronous function upward which nobody depends on, like an initialization function.

If you don't have any, you could write what we call IIFE, it's basically a self-invoked function, allowing you to do this :

// How can I achieve this ?

import prepareTable from './';

const table = await prepareTable; // <---- Error, it's not wrapped within an async function

// ----------------------------------------

import prepareTable from './';

(async function () {
  const table = await prepareTable; // 👍
})();

Here is what would look like our last example refactored with async/await

async function waiterJob() {
  try {
    const order = await gettingOrder();
    const dishes = await giveOrderToKitchen(order);
    await serveClient(dishes);
    startOver();
  } catch (error) {
    // Handle the error
  }
}

We'll wrap up here, we saw everything that will help you start with promises. If you are a more experienced developper and you think something is missing, please feel free to add a comment for it.

You can find the original article on the Othrys website and you can follow my Twitter or tag me here to discuss about this article.

The NPM guide I would have loved as a beginner

Chandelier Axel — Thu, 10 Dec 2020 21:09:24 +0000

As a junior developer, I struggled a lot with NPM.
Do you remember copy/pasting all the npm commands without knowing what they do ? Or the first time you freaked out while opening the package-lock.json ? What if I tell you that there's a bugs property that you can set in your package.json ?

No more fear is allowed from that point onward, we're going to learn together the basics of NPM.

Disclaimer - The article will follow my process of re-learning from scracth. Feel free to skip to specific parts if you don't want to read what NPM means, etc.

A little background
Initialization
Manage dependencies
Dependencies & DevDependencies
Side notes
- Uninstall a library
- Install specifid version
- The package-lock

A little background

Let's start with the basics, what does NPM even mean ? It stand for Node Package Manager, and as the name implies, it's responsible for managing your packages within your Node application.

Now considered as a major piece of Javascript ecosystem, NPM offer an easy way to manage all the external dependencies we'll need to use in our project with a pretty simple command : npm install .

I will skip the installation of NPM, the Node website will explain it to you properly, and is not the core of this article.

I'll jump straight to the npm commands. Let's start.

Initialization

When I typed my first npm commands, I had absolutely no idea what was going on, despite being the core of NPM. Let's see it in detail.

First of all, we need to create a node-based application, and this is as easy as running the following command.

    npm init

We'll be prompted a few questions about our project, such as the project name, the link to your Git repository, ect. But for now, let's just skip and press Enter.

Wait, use.

    npm init -y

Amazing, we skipped all the questions.

So, we now have a package.json filled with some informations.

{
  "name": "your_directory_name",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

This file can be considered as the ID Card of our application. It contains its name, the current version, a tiny description, some keywords to help other people finding it, and a bunch of other stuff.

(For a complete list of the properties, including the 'bugs' keyword we talked about, please refer to the official documentation).

You're also free to update it whenever you want, as long as you respect the JSON format and use the correct properties.

Next, we want to start our application, right ?

Scripts

Let's look at some examples. I'll assume you have worked at least once with either an Express-based application, or one of the popular JS front-end frameworks (such as React, Angular or Vue).

This scripts property give you the power to customize npm commands to use within your application.

Wait a second.. Is that the place were the npm start I use everyday is defined ? Exactly.

"scripts": {
    "start": "node index.js"
  }

You can specify any valid shells commands here, and create as much entries as you want nor need. You can even combine them !

"scripts": {
    ...,
    "stuffA:" : "...",
    "stuffB": "...",
    "together" : "npm run stuffA & npm run stuffB"
  }

(Beware, this will run your scrips in parallel. To run concurrently, either replace the "&" by "&&", or look at the Concurrently package).

Now, npm run together ! And yes, this is not a typo, you need to write the run keyword. In fact, even the npm start command is launched as npm run start behind the scenes. (This ability is shared with a couple other keywords, such as install, test..)

You still there ? Nice, let's keep digging and unleash the full power of NPM by adding some dependencies !

Manage dependencies

Nowadays, an npm package already exists for pretty much anything. It would be a shame not to use them, and to rebuild the wheel everytime.

This is probably the biggest role of the package.json, it'll keep track of all the dependencies within your project, including the versions.

    npm install <package_name>

This command will download all the files needed and install them into a brand new node_modules folder.
This folder will become bigger and badder as you'll install more and more packages (and the packages themselves most likely depend on others packages, which will be installed too).

Please don't do the same mistake as I did, and prevent committing this folder to your repository !

//.gitignore file at your project root

node_modules

Dependencies & DevDependencies

Meanwhile, in your package.json ..

"dependencies": {
    "express": "^4.17.1" <--- Package version
},
"devDependencies": {
    "eslint": "^7.13.0"
}

What is this ? Actually, it's quite simple. Whenever you'll install something through the npm install command, it'll list it there. Doing so, when you'll share your amazing project with the world, the others devs will only launch npm install and all the libraries required for your project to run, will install nicely.

Now what are devDependencies ? Everything that is not vital for your application and that should be removed from your production build will go there (such as your linter, for example). Be careful, you have to manage them yourself.

By default, the npm install command will put everything inside the regular dependencies. To put something in the devDependencies, you must pass an extra argument to the command :

    npm install --save-dev <your_library>

    npm install -D <your_library>

OR even shorter

    npm i -D <your_library>

Organizing your dependencies will lead to better production performance. You might not need your linter rules or your Typescript types definition to run your app, right ?

Even better, npm allow us to omit the devDependencies on installation !

    npm install --only=prod

Side (but important) notes

Uninstall a library

Made a typo and forgot the --save-dev in your command ?
Cleaning up your app from useless modules ?
You have two options, either remove the package and reinstall it again with the proper command, or do it manually in your package.json.

    npm uninstall <your_library>

This will remove the library from the package.json and from the node modules.

In case you want to remove it from the node modules but not from the package.json (let's say the installation failed for whatever reason).

  npm uninstall --no-save <your_library>

If you can't be bothered playing with the shell commands, you can also update manually your package.json.

Let's get back our previous example

"dependencies": {
    "express": "^4.17.1"
},
"devDependencies": {
    "eslint": "^7.13.0"
}

To remove the eslint dependency, erase it, and simply re-run npm install.

Install a specific version

Sometimes you'll have to install a specific version of a package. It's easy :

    npm install <your_library>@<version>

For example :

    npm install eslint@1.0.0

The package-lock.json

Last but not least, the package-lock. It's actually here to solve a problem from the package.json we haven't talked about.

We saw earlier that when installing a new package, his version is set into the package.json. It uses the semver convention.

Basically, the first character before the actual version number will implies some slight changes whenever the npm install command is ran.

    "express": "~4.17.1"

The ~ mean that NPM will go and look for the 4.17.1 version, but if a newer patch release is available, let's say 4.17.9, it'll use this one.

    "express": "^4.17.1"

The ^ mean that NPM will go and look for the 4.17.1 version, but if a newer minor release is available, let's say 4.18.1, it'll use this one.

    "express": "4.17.1"

If you omit a character, NPM will always use this exact version whatever happens.

If you always specify the exact version, the following problem I'll explain is already out of sight

Now let's say you have been working for a couple years on a project, and a new contributor clones and installs it.

Since a lot of time passed, some of our dependencies must have received some new releases. As we explained earlier, depending on your semver convention, NPM will look for potential newer versions...

And there we hit the wall, your project and the newly installed one are actually different because some dependencies do not match the version specified in the package.json.

Package-lock to the rescue. As his name implied, it'll lock the version number in stone and will guarantee that the same package version is installed on every subsequent installation.

You can find the original article on the Othrys website and you can follow my Twitter or tag me here to discuss about this article.

I'm going to convince you using React Hooks

Chandelier Axel — Fri, 16 Oct 2020 17:28:13 +0000

(If you are not using them yet, of course).

Quick intro

Lately, I've been working on a React app as part of my job. We are working with the usual React + Redux, with the old "class" way (which are still completely valid, don't get me wrong). But you know, hooks have been around for quite a while, and they are amazing. Let me show you why they are, and give me a chance to convince you using them.

Redux

If you have worked with Redux before, you know the drill:

Create the store
Wrap your application within the store
Connect the component with the HOC (Higher-Order-Component)
Create the mapStateToProps and mapDispatchToProps functions and applied theses to the connect ...

Pretty basic things that we do everyday, you may even have some VSC snippets to help you out.

State

Let's leave Redux for a second. How would you declare a state ?

Create your component
Call the constructor and the super
Create your this.state variable and fill it with values

~ Wait, in a real world exemple, there is more ...
~ You're right, let's add some lifecycles.

Lifecycles

In every real apps, you will have to gather some datas from your API endpoints. The best place to do so is within the ComponentDidMount. Sometimes, you even need to apply things on certains updates, it's where ComponentDidUpdate is coming handy. And of course you need to clean your subscriptions into a ComponentWillUnmount ...

A lot of things to remember, right ? And a lot of methods to write.

~ What if I can tell you that you can transform the 10+ lines declaration, into a 3 lines one ?
~ But, how ?!

With React Hooks feature, and this is how I'm going to convince you to give them a try.

Regular Class style exemple

Let's put everything we talked about inside this component ...

import React from 'react';

class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      // State ..
      user: {},
    };
  }

  componentDidMount() {
    // Fetch API endpoint
  }

  componentDidUpdate(prevProps, prevState) {
    // Apply effect based on changes ..
  }

  componentWillUnmount() {
    // Cancel subscriptions ..
  }

  render() {
    return <div>// Your app tree</div>;
  }
}

const mapStateToProps = (state) => {
  return {
    // Return some element from your state ..
  };
};

const mapDispatchToProps = (dispatch) => {
  return {
    //Return some functions that dispatch for you in the store ..
  };
};

export default connect(mapStateToProps, mapDispatchToProps)(App);

As you can see, without any logic specific code and JSX, the minimum required amount of code start to be substantial.

Functionnal Component exemple

Now the fun part, let's rewrite everything using some Hooks. Don't worry, we will do it step-by-step.

First, let's initialze your state:

import React, { useState } from 'react';

const App = () => {
  const [user, setUser] = useState({});

  return <div>// Your app ..</div>;
};

export default App;

Let's recap what is going on here. We use a React Hook called useState() which return a value, and a method to update this value. We also use the nice destructration synthax to get a super nice one liner.
(More informations on the useState here).

Next, let's add our lifecycles:

import React, { useState, useEffect } from 'react';

const App = () => {

    const [user, setUser] = useState({});

     useEffect(() => {

        // Equivalent of componentDidUpdate

        return () => // Equivalent of componentWillUnmount

    }, []); // Equivalent of componentDidUpdate.
    // It's an array of dependencies, add values there,
    // and React will re execute the useEffect whenever one of value changes

    return (
        <div>
            // Your app ..
        </div>
    )};

export default App;

Amazing, isnt it ? You can find more more infos here. But basically, React will always execute what is inside he useEffect on the first render, and will watch the value passed into the array to re-run the effect again. You'll return what you want to execute when the component unmount.

And last but not least, let's use Redux in there :

import React, { useState, useEffect } from 'react';
import { useSelector, useDispatch } from 'react-redux';

const App = () => {

    const [user, setUser] = useState({});

    const dispatch = useDispatch(); // Give access to the dispatch function
    const foo = useSelector(state => state.foo); // Recover the value from the store

    useEffect(() => {

        // Equivalent of componentDidUpdate

        return () => // Equivalent of componentWillUnmount

    }, []); // Equivalent of componentDidUpdate. It's an array of dependencies, add values there, and React will re execture the useEffect whenever one of value changes

    return (
        <div>
            // Your app ..
        </div>
    )};

export default App;

The code is pretty straightforward, buy it's only some very basic usages, you can gather more infos here. But bascially, you now have access to the dispatch function, and to whatever value you want without having to mapDispatch and mapState. Without even the connect, and our component is now connected implicitely.

Conclusion

Well, nothing to conclude on, really. But take a second, and compare both code snippets. The result is stunning, you saved so much code for doing the exact same thing.
I'll link you the react official documentation here, and you can scroll down to a youtube video that does an amazing convertion from class to hooks.

Now, tell me, are you convinced to give them a try ?

You can find the original article on the Othrys website and you can follow my Twitter or tag me here to discuss about this article.

Have a nice day.

How does React work under the hood (JSX wise) ?

Chandelier Axel — Sun, 11 Oct 2020 20:40:58 +0000

You're using JSX every days without a clue how React does his magic ? Ever wondered why we do have to wrap our elements in a parent ? (JSX expressions must have one parent element. 🤯🤯🤯)

Well, this article is for you. I'll do my very best to explain it to you, as I understood it. Keep in mind that's nobody is perfect, and if there's any mistake made, feel free to discuss it on Twitter, we're all learning everyday :D.

How does our JSX work ?

First things first, we have to make sure that you actually know how to insert new elements into your HTML with JavaScript. If you already know that, feel free to skip, if you don't, well ... Keep reading.

In a regular HTML/JS website, here's how you would do :

<body>
  <div id="root"></div>
</body>
<script>
  // You first get the targetted element
  const parent = document.getElementById("root");
  // Then you create the new one
  const newChildren = document.createElement("div");
  // And you append it to the parent it belong to
  parent.appendChild(newChildren);
</script>

Pretty straightforward, right ? But you noticed that it does create an empty element, you probably want to add at least some text, and even some attributes such as an id.

<body>
  <div id="root"></div>
</body>
<script>
  const parent = document.getElementById("root");
  const newChildren = document.createElement("div");

  newChildren.setAttribute("id", "children");
  newChildren.innerHTML = "Hello World !";

  parent.appendChild(newChildren);
</script>

Your HTML page would now render a div, with an id of 'children', containing the 'Hello World' text, and so on for any other elements you want to create (you could write functions to help you out, but that's not the point or this article). It can become a mess really quickly, right ?
You would have to handle every attributes you want to add, every listeners, etc. You get the idea.

Now, how does React work ?

React does expose to use 2 libraries for the web developement : React and ReactDOM. Let's say you do have initialized your React project from create-react-app and it's running properly. Ultimately, once you have removed everything that is not necessery, you have a code looking like this :

import React from "react";
import ReactDOM from "react-dom";
import App from "./App";

ReactDOM.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
  document.getElementById("root")
);

Let's get rid of the abstraction for now, and remove the JSX syntax, we'll come back on it later.

import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';


ReactDOM.render(
    /* Insert your elements here */ ,
    document.getElementById('root')
);

This function is the entry point of your React App. You are telling React to get a div with the id of 'root', and to render inside of it everything you'll pass as the first argument.

Now, how do we actually create elements ? This render function won't accept anything that is not a valid React element. Let's get into it with the raw React API we imported.

const element = React.createElement("div", null, "Hello World");

ReactDOM.render(element, document.getElementById("root"));

The create element function take 3 arguments :

The type of the HTML element you want to create (div, span, input...)
Some props that I'll explain juste after. For now the value is null as we don't want any
And the children which is basically anything that will be inserted inside this new element created.

Now, what if we want to give an id to this element ?

const element = React.createElement("div", { id: "children" }, "Hello World");

This is where the second argument is used. It does accept an object of properties that will be applies to your element, here we added an id, but you could do it for a class, or some specific attributes for your tag. Even on onclick event !

const element = React.createElement(
  "div",
  {
    id: "children",
    onClick: () => console.log("Hello"),
  },
  "Hello World"
);

Way better than the regular JS declaration.

(As a side note, keep in mind that the last parameter is not mandatary, and you could give in the props with the children key)

React.createElement("div", { children: "Hello World" });

What if we have more than one child to render inside your div ?

const element = React.createElement("div", {
  id: "children",
  onClick: () => console.log("Hello"),
  children: [
    React.createElement("span", {
      children: "Hello World, ",
      style: { color: "red" },
    }),
    React.createElement("span", {
      children: "this is ",
      style: { color: "green" },
    }),
    React.createElement("span", { children: "Foo Bar !" }),
  ],
});

The children property accept an array of elements, and obviously you could do that as long as you want, and this is actually how your JSX code look like in reality.

If you have been using React for a bit before reading this, you should now have a better insight of why you're doing certain things (such as style={{color: 'red'}}), but we'll come on it later.

Well, I ain't writing that anyway, how does this is useful ?

Indeed, this is pretty annoying to write, and nobody using React will use it with the raw API. That's where React introduced JSX.

JSX is basically a sugar synthax for writing the code above, thanks to Babel. (If you don't know what Babel is, it bascially take your code, and convert it into a browser compatibile version, more infos here).

So if you write that :

const component = () => <div id="children">Hello World !</div>;

It'll actually be compiled by Babel as :

const component = React.createElement("div", { id: "children" }, "Hello world");

Now, what if we rewrite the previous example with the list of elements in JSX ? It would look like this :

const component = () => (
  <div id="children">
    <span style={{ color: "red" }}>Hello World, </span>
    <span style={{ color: "green" }}>this is </span>
    <span>Foo Bar !</span>
  </div>
);

Amazing, isnt it ? It's way cleaner than the raw React API.

Let's recap what we learned so far, but starting from JSX :

You write your JSX code, which is compiled by Babel to make actually readable.
The result is a call to the React.createElement() function with the correct parameters.
And now what ? Well, React is doing one more trick for us : He's making one more abstraction, and doing the document.createElement() function for us.

As an exemple, I've been digging and I found a pseudo code wrote by Dan Abramov.

var node = document.createElement(type);
Object.keys(props).forEach((propName) => {
  if (propName !== "children") {
    node.setAttribute(propName, props[propName]);
  }
});

children.filter(Boolean).forEach((childElement) => {
  var childNode = mount(childElement);

  node.appendChild(childNode);
});

We see that React is doing exactly what we did at the beginning, create a new node, setting attributes if needed and appending it into the DOM with the help of the virtual DOM (I'll probably talk about it in another blog post).

You can also find the full pseudo code here.

Miscellaneous

Why I am passing an object for style inside the JSX ?

Whenever you'll want to apply inline style to your JSX element, you'll have to wrap the styles inside an object. Why ? Because doing the following won't make any sense :

const element = React.createElement(
    'div',
    {
        id: 'children',
        onClick: () => console.log('Hello'),
        // Your browser would obviously complain
        style : color : red
    },
    'Hello World');

Right ? And this is exactly what you're telling Babel to do by writing this :

<div style={color: 'red'} >Hello World</div>

And that's also why you can't embed any kind of statements inside your JSX, such as if...else.

How Babel does understand the difference between an html tag, and a custom component ?

By capitalizing your component. That's all. If you create a component without capitalizing it, Babel will understand it as a potention html tag, and so will create it.

<component>My custom component</component>

Not what we wan't.

Why do we need to wrap our elements into one parent ?

It's because on how the React API work, let's say you write this :

const component = (
    <div>Hello </div>
    <div>World !</div>
);

React will complain about having a parent, because Babel will compile it this way :


const element = React.createElement('div',
    {
        id: 'children',
        children: 'Hello World !', 'ae'
    }
);

Weird again, right ? You could wrap everything into an array, and return this way :

const component = [
    <div>Hello </div>
    <div>World !</div>
];

But this is not really how it is suppose to be used, hence why you need a parent.

Ending

We'll wrap it up for now, hope your enjoyend and learnt something. Again, feel free to send my feedback nor mistakes, I'll appreciate it !

You can find the original article on the Othrys website and you can follow my Twitter or tag me here to discuss about this article.

Have a nice day.

Why you should cancel your API calls in React ?

Chandelier Axel — Mon, 05 Oct 2020 16:32:38 +0000

Explanation

We all know it, every web application make API calls, even the tiniest do so. ( Remember that first Todo app you made with a cat API ?).

You’ll gather some data, render it and do whatever you like on the website.. The real problems arises when either your internet is slow, or the data you need to gather is huge.

Imagine if you need to gather that huge amount of data with barely an Edge connection.. It will take a couple of seconds, at least, to get everything from the API endpoint, right ? What if your user go on another page ?

If you thinked :

« Uh - Nothing, it’s not a big deal anyway. At most the data is uploaded and nothing will happen. »

Well.. You are partially right, NOTHING will happen. Thanks to our job, making mistakes is riskless - most of the time at least, but there’s always place for improvement and it’s our duty to free up as much network space as we can, and make our apps less data consuming.

Without forever teasing, let’s dive straight into it.

Cancelling the calls

First, I created a simple app which render only 2 components :

One who will be responsible to make the API call, and to render a button who will handle the redirection.
The other component will only render a string.

const App = () => {
    const [apiCallDone, setApiCallDone] = useState(false);

    return (
        <div className="App">
            {apiCallDone
                ? <AnotherComponent />
                : <ApiCallComponent redirectToOtherComponent={setApiCallDone} />
            }
        </div>
    );
}

As you can see, once the apiCall will be set as true, App.js will re-render and show the other component.

Now let’s take a look at the component that make the actual call.

const ApiCallComponent = ({ redirectToOtherComponent }) => {

    const [result, setResult] = useState([]);

    useEffect(() => {
        fetch('https://pokeapi.co/api/v2/pokemon/12')
            .then(res => res.json())
            .then(data => setResult(data))
    },[]);

    const redirect = () => {
       redirectToOtherComponent(true)
    };

    return (
        <button onClick={redirect} > Let's call the APi </button>
)
};

As you can see I reproduce a really simple component, that will make a call to the Pokémon API as soon as it’ll mount. And the button will trigger the function we passed in the props.

Nothing fancy, right ? We literally made a really minimal representation of all our apps - Gather data, consume it, and possibly show a different view / redirect.

Now let’s add some lags into our call by adding a timeout. Doing so we’ll mimic the slow internet.

  useEffect(() => {
        setTimeout(() => {
            fetch('https://pokeapi.co/api/v2/pokemon/12')
                .then(res => res.json())
                .then(data => setResult(data))
                .catch(err => {
                    // Handle error ..
                })
            }, 3000);
    });

Now let’s try to make our call, and to click on the button within the 3 seconds timer ..

Here’s what we were looking for. And I bet you know what this error is. It means that you’re trying to update a component state while the component was unmounted. In our exemple, it’s literally because we didn’t cancel our api call on the unmount.

Fetch cancel

To fix this with the fetch API :

useEffect(() => {
    // First, create a controller, more infos there : https://developer.mozilla.org/en-US/docs/Web/API/AbortController
    const controller = new AbortController();

    setTimeout(() => {
        // Then give it in the fetch options, so the controller is properly linked
        fetch('https://pokeapi.co/api/v2/pokemon/12', {signal: controller.signal})
            .then(res => res.json())
            .then(data => setResult(data))
            .catch(err => {
                // Handle error ..
            })
    }, 3000);

    // Then on the "unmount" of the component, abort the API call ..
    return () => controller.abort();
}, []);

That's all !

Axios

useEffect(() => {
    // More informations about the cancelation for the axios library here : https://github.com/axios/axios#cancellation

    const CancelToken = axios.CancelToken;
    const source = CancelToken.source();

    setTimeout(() => {
        axios('https://pokeapi.co/api/v2/pokemon/12', { cancelToken: source.token })
            .then((res) => setResult(res.data) )
            .catch((err) => {
                // Handle error..
            } )
    }, 3000);

    return () => source.cancel();
}, []);

Congratulation ! You’ve now cleared your console from this filthy errors !

No more excuses when you'll create an API call, you now have all the tools to handle it properly.

You can find the original article on the Othrys website and you can follow my Twitter or tag me here to discuss about this article.

Have a nice day !

DEV Community: Chandelier Axel

Everything is a file in UNIX ?

Table of contents

Is everything really a file ?

What is a file, if everything is a file ?

Inode

Basics

Inode number

File name and directories

The file data

Why do React need to be in scope for JSX ?

React must be in scope when using JSX

Table of contents

Why are we getting this error ?

How to fix ?

React version 17 and beyond

How to handle your JWT in your applications ?

What is the problem ?

Local Storage

XSS Attack

HttpOnly Cookie

XSRF Attack

Storing it into memory

Having a refresh_token

Wrapping up

Javascript Modules

A bit of history

AMD, CommonJS, UMD

ES6, export and import

Basics

Named exports/imports

Default exports/imports

Fancy but useful features

Mixing named and default exports/imports

Renaming

Import everything at once

Using await in loop cause performance issues

The test

The refactor

Explanation

Conclusion

A complete introduction to Docker

Introduction

VM (Virtual Machine)

The theory

The hotel comparison

The downsides

How Docker solve this ?

Docker basics

The containers

The images

My experience from bootcamper to freelancer.

Table of contents

My journey

Make personal projects

Stop following tutorials blindfolded

Ask dumb questions

Share your success

Prioritize group activities

Be focused

Learn how to write tests

Don't be affraid to accept technical challenges

Teach

The Promises guide I would have loved as a junior developper

Table of contents

Necessary background informations

So, what are Promises ?

Why do we need them ?

Let's dig into the code

How can I use them ?

How can I recognize a Promise I didn't write ?

Additional informations

Async / Await

The NPM guide I would have loved as a beginner

Table of contents

A little background

Initialization

Scripts

Manage dependencies

Dependencies & DevDependencies

`React must be in scope when using JSX`