Many React developers struggle to understand the difference between useMemo() and useCallback() and when to use each of these hooks. In this blog post I'll try to explain this and make it a bit clearer for you.

---
> Please note : It's best if you read this blog post after you have some knowledge of React. If you're an absolute React beginner, I'd suggest you bookmark this blog post and come read it in a couple of weeks, when you have a better understanding of React
---
## re-rendering ? 
React  "re-renders" to keep our UI in sync with our application state as it gets updated. 
This is one of React's main features. Each re-render is a "snapshop" of the UI in a specific moment, based on the application's state. We can think of it as PostIt notes, stacked one on of another, that hold the state of the application. Everytime we add a new PostIt note, the UI gets "re-rendered" to reflect it.

What gets re-rendered, is a "picture" of what the DOM should look like. It's presented as HTML but in reality it's a bunch of JS Objects. On every re-render, React compares the new snapshot, with the last one and figures out which UI Components it needs to update.

While React is greatly optimized to manage these updates, it might take a while to create these snapshots under certain circumstances, making the UI updates feel "slow" or "laggy", leading to performance issues.

And this is where *useMemo()* and *useCallback()* hooks come into play, by reducing the amount of work needed to be done in a render and reducing the number of times a component needs to re-render.

## useMemo() hook
useMemo() allows us to "memorize" a value between renders. This can be helpful when we have heavy computations to make or when we need to preserve our references between renders

### Case 1 : Heavy computations

Let's suppose we create a tool that returns the fibonacci suite up to a given number. As you can imagine, in case of a huge number input, there will be a great amount of calculations to be executed.

<iframe src="https://codesandbox.io/embed/blog-usememo01-esqo9e?fontsize=14&hidenavigation=1&theme=dark"
     style={{width:"100%", height:"500px", border:0, borderRadius: "4px", overflow:"hidden"}}
     title="blog/useMemo01"
     allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
     sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
   />

For every user picked number, we have to go (possibly) through *tens of thousands of numbers* which is computationally intensive no matter how much we optimize our algorithm.

As you can imagine, we need to perform the calculations *sometimes* (when user changes the input value) but not everytime the component is rendered.

For example, let's add a digital clock in our previous example :

<iframe src="https://codesandbox.io/embed/blog-usememo02-g0o2jk?fontsize=14&hidenavigation=1&theme=dark"
     style={{width:"100%", height:"500px", border:0, borderRadius: "4px", overflow:"hidden"}}
     title="blog/useMemo02"
     allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
     sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
   />

In this example, we have added a new piece of state, called 'time', which gets updated every second to reflect the current time.

But what also happens is that the fibonacci calculation is **re-run** on *every* render, which means we are constantly regenerating the list of fibonacci suite number even when the user didn't update the input number. You can see that we console.log 'Rendered' every second.

This can create performance issues because JavaScript is a single threaded process. Keeping this thread extremely busy and can make our application feel sluggish, especially on lower-end devices.

This is when useMemo comes into play. It allows us to **"skip" these re-calculations** since it reuses the already generated result unless the input is altered by the user.

```js:useMemo.js
const fibonacciSuite = React.useMemo(()=>{
	return getFibonacciSuiteNumbers(selectedNum)
   }, [selectedNum])
   ```
   
   useMemo takes two arguments: 
1.  A block of work to be executed wrapped up as a functions.
2. A list of dependencies.


How it works : 
React checks if any of the values in the dependency list has changed. If any of the values has changed, React will re-run the supplied task and calculate a new value. Otherwise, it will just keep the previously calculated value. In other words, it's as if we were saying : "Recalculate the fibonacci sequence ONLY when the selectedNum value changes." This is known as *memoization*, and this is why the hook is called "useMemo"

Here's an example of how we could do this : 

<iframe src="https://codesandbox.io/embed/usememo03-b71jgo?fontsize=14&hidenavigation=1&theme=dark"
     style={{width:"100%", height:"500px", border:0, borderRadius: "4px", overflow:"hidden"}}
     title="blog/useMemo03"
     allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
     sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
   />


### Case 2 : Preserving references

In the following example we have a "Cards" component which displays a set of cards. The information about the cards is saved in an Array called "cards". We also have some unrelated state such as "time".

As you can see we are wrapping it in a useMemo hook. "Boxes" is a *pure component*, meaning that it should only re-render whenever its props change (in this case "cards") :

-*so it shouldn't recalculate its values when "time" state gets updated, right ?*
-**WRONG**
-*But useMemo should protect the component from this issue.. what is happening ?*

This goes back to the basics of JavaScript and how it works under the hood. In JavaScript, everytime React re-renders, we create a *new array*. And in JavaScript, two arrays can be equivalent in **value**, but they can be **referencing** different objects

<iframe src="https://codesandbox.io/embed/usememo04-reference-rdxb30?fontsize=14&hidenavigation=1&theme=dark"
     style={{width:"100%", height:"500px", border:0, borderRadius: "4px", overflow:"hidden"}}
     title="useMemo04 - Reference"
     allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
     sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
  />

As you can see in the example... both arrays are exactly the same in their contents, but they are **not equal** in terms of *reference*.

so when we use '===' we don't only check the contents, but we also check if the two values are actually the *SAME THING*. 

Imagine having two identical twins... *they look the identical but they are 2 completely different persons*.

<iframe src="https://codesandbox.io/embed/musing-antonelli-ch6hm1?fontsize=14&hidenavigation=1&theme=dark"
     style={{width:"100%", height:"500px", border:0, borderRadius: "4px", overflow:"hidden"}}
     title="useMemo05 - reference cards"
     allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
     sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
   />

Since components in React are mainly JavaScript Functions... everytime we render it, we are invoking that function, creating a *new* array in the process.

When the "time" state changes, our "App" component re-renders, a new "cards" array is constructed, and by passing it onto our "Cards" component, we get a re-render since the previous Array is not the same as our new Array in terms of *reference*

We can solve that with the following piece of code :

``` js:reference.js
const cards = React.useMemo(()=> {
	return [
    	{ cardId: 0, cardContent: 'I am a card' },
        { cardId: 1, cardContent: cardText },
      ]
}, [cardText]
```
<iframe src="https://codesandbox.io/embed/usememo06-reference-cards-solved-ecbsz1?fontsize=14&hidenavigation=1&theme=dark"
     style={{width:"100%", height:"500px", border:0, borderRadius: "4px", overflow:"hidden"}}
     title="useMemo06 - reference cards solved"
     allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
     sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
  />
   
We do want the cards to re-render when "cardText" changes, but not when "time" does. useMemo() preserves the reference to "cards" between re-renders, that way it will ignore all the renders that don't affect the UI.

---
Check the console log to see the rerenders in real time
---

## useCallback() hook

We have "useMemo()" covered... but what about "useCallback()" ? 

I have good news for you ! "useCallback()" is the same exact thing, but for *functions* instead of arrays/objects.
Functions are compared by reference as well, this means that if we define a function within our component, it will be replaced on every single render, creating a unique function each time.

<iframe src="https://codesandbox.io/embed/usecallback01-7gbbnl?fontsize=14&hidenavigation=1&theme=dark"
 style={{width:"100%", height:"500px", border:0, borderRadius: "4px", overflow:"hidden"}}     
     title="useCallback01"
     allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
     sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
  />
This example containts a typical todo app, with the ability to increment a counter 

The "Todos" component is memoized thanks to React.memo but as we already saw before, it'll be rerendered whenever the counter value changes.

We could solve this with "useMemo()" as we've already learned , while this works, there is a better way.

<iframe src="https://codesandbox.io/embed/usecallback02-xkewl0?fontsize=14&hidenavigation=1&theme=dark"
 style={{width:"100%", height:"500px", border:0, borderRadius: "4px", overflow:"hidden"}}     title="useCallback02"
     allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
     sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
   />

*useCallback()* is exactly the same as *useMemo()*, but it's built to memoize functions.
Put differently the following two examples have the same result 

```js:useMemo_VS_useCallback.js
React.useCallback(function helloWorld(){},[])
// and
React.useMemo(() => function helloWorld(){},[])
// will function the same way
```

Seing this, you can easily deduct that *useCallback is syntactic sugar*. It exists to make our lives easier when we want to memoize functions.

---

## Ok, but how often should I use them ?

I can already hear some of you asking the following question : 
*"Vasili, thank you for explaining this to me, but when and how often should we REALLY use them ?*

In my opinion, the best moment to use these hooks is when you really have issues with performance. 
When you notice your app is getting sluggy and slow, you can use the *React profiler* and narrow the issue to the components that have slow renders. Most of the cases your remedy will be to restructure your application, but in some cases *useMemo* and *useCallback* can help you speed things up.

here are some scenarios that I use these hooks without any second thought : 

### Context providers

When sharing data with context within an application, it's common to pass big objects as the value attribute.

```js:AuthContext.js
const AuthContext = React.createContext({});
function AuthProvider({ user, status, children }){
  const memoIzedAuthState = React.useMemo(() => {
    return {
      user,
      status,
      
    };
  }, [user, status]);
  return (
    <AuthContext.Provider value={memoizedAuthState}>
      {children}
    </AuthContext.Provider>
  );
}

```

Since this context might be consumed by n number of pure components, it is beneficial to use useMemo. Otherwise, all the components consuming the context will have to re-render if *AuthProvider*'s parent happens to re-render.


---

*Finally you reached the end of this blog post. Please remember to share and to bookmarki this post if you enjoyed reading it and if it helped you. 
Thanks in advance,
Vassili*




How (and when) to use useMemo() and useCallback()

We can use *Promise.all()* to wait multiple promises to resolve before going on with our code.

But there is a small problem here... 
When we use *Promise.all()*, if **ONE** of the promises is rejected because of an error, we lose the data from all the other promises that successfully fulfilled and returned data.

```js:PromiseAll.js
const responses = await Promise.all([
    getPosts(),
    getUsers(),
    getShops(),
    getPrices()
]).catch(console.error)

for (const response of responses){
    // do stuff with your responses array loop
    console.log(response.data)
}

console.log(reponses)

//if an Error 404 happens on getPrices(), above code will return the following
```
![Promise.all rejected](https://hq.theweeklydev.com/assets/707e6a1e-29ef-4463-b8dc-2231f8431337)---

*But what if we want to keep the data from the resolved promises ?*

That's where *Promise.allSettled()* comes into play

let's adapt our code a little bit

```js:PromiseAllSettled.js
const responses = await Promise.allSettled([
    getPosts(),
    getUsers(),
    getShops(),
    getPrices()
]).catch(console.error)

// Promise.allSettled() returns information about all the promises in the array

for (const response of responses){
	// Check if promise was rejected
    if (response.status === 'rejected') continue;
    
    // do stuff with your resolved promise data.
    console.log(response.value)
}

console.log(responses)
```

![Promise.allSettled](https://hq.theweeklydev.com/assets/6b4df0c6-71a5-48b4-a1fa-1822570344bb)


---

*Promise.allSettled()* will fire when all our promises have been fulfilled or rejected. 

We then use *if (response.status === 'rejected') continue* to skip promises that rejected and continue with the rest of them, keeping their results in the process.


When to use Promise.allSettled() and how is it different from Promise.all()? 

# About Arrays and their mutations
As we know, JavaScript stores objects and arrays in heap storage. 
That means the memory assigned for a specific array / object is dynamic and once the array has been created. And we don't always want this. 

```js:ArrayMethods.js
let demoArray = [ 'a', 'b', 'c'];
let newArray = demoArray;

newArray[0] = 'd';

console.log(demoArray); // ['d', 'b', 'c']
console.log(newArray); // ['d', 'b', 'c']
```

Because of that, we often find ourselves creating copies of the arrays to apply our changes without mutating the original. This is usually done with the <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax" target="_blank" rel="noopener">spread (three dots) operator</a>

```js:SpreadOperator.js

const numbersArray = [1, 2, 3];
let numbersArrayCopy = [...numbersArray];

numbersArrayCopy[0] = 5;
console.log(numbersArray) // [1, 2, 3]
console.log(numbersArrayCopy) // [5, 2, 3]
```
Since cloning arrays is so common when we want to keep the original immutable, a new specification reached stage 3.

The following proposal, is what introduces these methods and I'm pretty sure everyone will welcome them with excitement. Read more regarding the <a href="https://github.com/tc39/proposal-change-array-by-copy" target="_blank" rel="noopener"> *"Change Array by copy"*</a>

If you want to check this out, here is a <a href='https://github.com/tc39/proposal-change-array-by-copy/blob/main/polyfill.js' target='_blank' rel='noopener'>polyfill</a> that recreates the proposal's behaviour.

# New Change Array by Copy methods

The proposal adds 4 new methods which will copy an array and then apply the changes. These methods are the following : 

- *Array.prototype.toReversed()* - Clones an array, and then reverses it.
- *Array.prototype.toSorted(compareFn)* - Clones an array, and then sorts it.
- *Array.prototype.toSpliced(start, deleteCount, ...items)* - Clones an array, and splices it in some way
- *Array.prototype.with(index, value) - Clones an array, and adds a new element in the index you provide

##### toReversed()
*toReversed()* does exactly what it says. It clones an array, and reverses the order of the values in it. Since this method clones the array, we don't need to do any manual copy of the original to create a new version :
```js:toReversed.js
let arrayA = [ 'a', 'b', 'c' ];
let arrayB = arrayA.toReversed();

console.log(arrayA, arrayB); // Returns [ 'a', 'b', 'c'], [ 'c', 'b', 'a' ]
```

##### toSorted()
*toSorted()* is the immutable version of sort(), meaning it will not mutate (alter) the original array. It will clone it instead and sort it (numerically by default) :

```js:toSorted.js
let x = [ 5, 1, 2, 4, 3];
let y = x.toSorted(); // returns [ 1, 2, 3, 4, 5 ]
```

You can also use a comparison method exactly like the *sort()* method in JavaScript, and it is really useful when we want to sort an array of objects :

```js:toSortedObjectArray.js
let arrayA = [
    { value: 1 },
    { value: 5 },
    { value: 3 },
    { value: 4 },
    { value: 2 }
];


let arrayB = arrayA.toSorted((a, b) => {
    return a.value - b.value
});

console.log(arrayB);
// [
//	  { value: 1 },
//    { value: 2 },
//    { value: 3 },
//    { value: 4 },
//    { value: 5 }
// ]
```

##### toSpliced()
*toSpliced()* is the immutable version of *splice()*. It doesn't alter the original array and accepts 3 arguments: 
- *start* - the position to start at.
- *deleteCount* - the number of elements to remove.
- *...items* - any items to insert at index after deletion.

```js:toSpliced.js
let x = [ "Car", "Bike", "Scooter", "Motorcycle", "RollerBlades", "Skateboard" ];


let y = x.toSpliced(1, 2, "Train"); //y=[ "Car", "Train", "Bat",  "Motorcycle", "RollerBlades", "Skateboard" ]


let z = x.toSpliced(1, 3); // z=[ "Car", "RollerBlades", "Skateboard" ]
```

as you can see, this is an example of how useful these new methods are. 
The original array would've been mutated had we used the *sort()* method, but with *toSpliced()* we can use the original array as many times, without worrying about altering it.

##### with()
Last, we have *with()*, which takes an array, and returns a clone of it "with" a something we declare : 
```js:with.js
let x = [ "Car", "Bike", "Scooter" ];

let y = x.with(1, "Train"); // y=["Car", "Train", "Scooter"]

let z = x.with(0, "Skateboard"); // z=["Scateboard", "Bike", "Scooter"]
```

## Conclusion

This is a very welcome addition to JavaScript. It was needed, since JavaScript maintains only one copy of the an object or an array. With these new methods, the complexity of keeping the the original array untouched ir removed and the readability of the code improves a lot.

New array methods coming in JavaScript

A Type Guard is a technique used to test if a value is of a specific type depending on the boolean returned by a regular function that contains (usually) a conditional block. This technique is used to make sure that the tested value is of that specific type we are checking for.

Type Guards are pretty helpful as you can imagine. One example could be that we retrieve data from an API but we don't know if that returned value is of the Type we are looking for. To do so we can create a "User Defined Type Guard"

Let's see how it is done.

```ts:retrieve-pancake.ts

let couldBePancake: unknown  // Api response retrieved

// Custom typeguard function
type Pancake = {
	name: string;
    variant: 'salty' | 'sweet';
    toppings: number;
    totalPrice: number;
 }
 
 	console.log(couldBePancake.name) // Object is of type unknown
 
```

in the example above, we cannot use 'couldBePancake.name' because we don't know yet if it is of type 'Pancake'. We need to implement the following :


```ts:retrieve-pancake.ts

let couldBePancake: unknown  // Api response retrieved

// Custom typeguard function
type Pancake = {
	name: string;
    variant: 'salty' | 'sweet';
    toppings: number;
    totalPrice: number;
 }
 
 // Exhaustively checking if obj contains all attributes of Pancake
 function isPancake(obj: any): obj is Pancake {
 	return obj.name && obj.variant && obj.toppings && totalPrice
 }
 
 // calling the guard type
 if (isPancake(couldBePancake)) {
 	console.log(couldBePancake.name) // no errors here
 }
 
```

Since we narrowed the type down to make sure it is a Pancake, we can use couldBePancake.name. 

In short our logic goes like "If this is indeed of Type Pancake, then we can go ahead and use couldBePancake.name ." And all our TS errors are gone.

We have to take note that TypeScript doesn't assume type guards remain active in callback as making this assumption is dangerous.



```ts:retrieve-pancake.ts

let couldBePancake: unknown  // Api response retrieved
let basePrice: number; // comes from configuration

// Custom typeguard function
type Pancake = {
	name: string;
    variant: 'salty' | 'sweet';
    toppings: number;
 }
 
 // Exhaustively checking if obj contains all attributes of Pancake
 function isPancake(obj: any): obj is Pancake {
 	return obj.name && obj.variant && obj.toppings && totalPrice
 }
 
 // calling the guard type
 if (isPancake(couldBePancake)) {
 	console.log(couldBePancake.name)
    // BUT this will not work
    calculateTotal(()=> {
    	console.log(couldBePancake.toppings * 1.1 + basePrice) // TS Error: Object is possibly 'undefined'
    }
 }
 
```


if we want to fix this 'issue' we can simply store the inferred safe value in a local variable. That way TypeScript can easily understand that it doesn't get changed externally.




```ts:retrieve-pancake.ts

let couldBePancake: unknown  // Api response retrieved
let basePrice: number; // comes from configuration

// Custom typeguard function
type Pancake = {
	name: string;
    variant: 'salty' | 'sweet';
    toppings: number;
 }
 
 // Exhaustively checking if obj contains all attributes of Pancake
 function isPancake(obj: any): obj is Pancake {
 	return obj.name && obj.variant && obj.toppings && totalPrice
 }
 
 // calling the guard type
 if (isPancake(couldBePancake)) {
 	console.log(couldBePancake.name)
    const numOfToppings = couldBePancake.toppings
    calculateTotal(()=> {
    	console.log(numOfToppings * 1.1 + basePrice) // TS understands that numOfToppings inferred type is "number".
    }
 }
 
```

User Defined Type Guards in TypeScript

So you have read a couple of tutorials, followed some youtube videos and learned the basics of JavaScript, but what's next ? 

I will share with you some of the repositories that will help you sharpen your skills in JavaScript and try to order them by level of JS knowledge needed from 0 to 100%.

---

**"Hello world"**

- <a href="https://github.com/GitbookIO/javascript" target="_blank" rel="noopener noreferrer">Learn Javascript by GitBook</a> - A free book that can teach you the basics of programming and JavaScript. This is a great intro to JavaScript and programming in general.

**Beginners that know some stuff**

- <a href="https://github.com/wesbos/JavaScript30" target="_blank" rel="noopener noreferrer">JavaScript30 Challenge</a> by Wes Bos is an Awesome 30-day challenge for JavaScript beginners that will help you apply everything you learned in daily projects. A good way to also create a basic portfolio as a junior JS developer.

**Ok, so that's how it works !**

- <a href="https://github.com/leonardomso/33-js-concepts#33-clean-code" target="_blank" rel="noopener noreferrer">33 concepts every javascript developer should know</a> by Leonardo Maldonado. A huge list of links to blogs and sources that will teach you how JavaScript works under the hood. Something every JavaScript developer should be a master of.


**Let's check what's going on under the hood**

- <a href="https://github.com/humanwhocodes/computer-science-in-javascript" target="_blank" rel="noopener noreferrer">Computer Science in JavaScript</a> by Nicholas C. Zakas. *A collection of classic computer science paradigms, algorithms and approaches written in JavaScript*

**Bring the heavy artillery**

- <a href="https://github.com/TheAlgorithms/JavaScript" target="_blank" rel="noopener noreferrer">The Algorithms - JavaScript</a> - A huge collection of all algorithms implemented in JavaScript following best practices.

**Little bonus**

- <a href="https://github.com/30-seconds/30-seconds-of-code" target="_blank" rel="noopener noreferrer">30 Seconds of Code</a> by 30secondsofcode.org. Hundreds of JavaScript snippets, that will help you speed up your development process while keeping your code clean and efficient.

The above repos should provide you with everything you need to sharpen your skills and become a better JavaScript developer.

If this article helped you, don't forget to share it.

GitHub repositories that will help you become a better JavaScript developer

In TypeScript you can do exhaustive checking with '*never*'. You can make sure you cover every possible scenario and avoid forgetting one especially if you add it later in your code.

You can add a 'switch' case and make sure that everything that is outside my case should never happen

```ts:main.ts

const rateMultiplier = 1.5

type Car = {type: 'car' , rate : number}
type Motorbike = {type: 'motorbike', rate: number}
type Vehicles = Car | Motorbike

function getRate(vehicle : Vehicles) {
	switch (vehicle.type) {
    	case 'car' : 
        return vehicle.rate * rateMultiplier;
        
        case 'motorbike':
        return vehicle.rate * rateMultiplier - (vehicle.rate * discountAmount);
        
        default : 
        // This should never happen !
        let shouldNeverHappen : never = vehicle;
        return shouldNeverHappen;
    }
}
```

Let's say a developer comes back at a later stage and adds a new vehicle type in without adding it to the switch statement. In that case the dev will be informed by TypeScript that the new vehicle type was not accounted for in the switch statement

```ts:main.ts

const rateMultiplier = 1.5

type Car = {type: 'car' , rate : number}
type Motorbike = {type: 'motorbike', rate: number}
type Bicycle = {type: 'bicycle', rate: number} // We added Bicycle here

type Vehicles = Car | Motorbike | Bicycle // and here

function getRate(vehicle : Vehicles) {
	switch (vehicle.type) {
    	case 'car' : 
        return vehicle.rate * rateMultiplier;
        
        case 'motorbike':
        return vehicle.rate * rateMultiplier - (vehicle.rate * discountAmount);
        
        default : 
        // This should never happen !
        let shouldNeverHappen : never = vehicle;
        return shouldNeverHappen; // Type 'Bicycle' is not assignable to type 'never'.
    }
}
```

As you can see above, TypeScript detects the possibility of Bicycle being used, but since it was not included in the switch statement, the default part is now reached, and it is of type 'never'. That returns a TypeScript Error reminding us that we need to include 'bicycle' within our switch statement. (and anywhere where it could be called in our codebase)

Another example of a case where this could be useful 

let's say we have an article with sizes.

```ts:item-size-calc.ts

type SizeOptions = 's' | 'm' | 'l' | 'xl' 


function getSizePriceVariant(size : SizeOptions) {
	 if (size === 's' || size === 'm') {
    	return 1;
    } else if (size === 'l' || size === 'xl') {
    	return 1.2;
    }
    
    // This code should be unreachable
    const neverHappens: never = size;
    return neverHappens;
}
```
Again, if a developer adds another size options but without accounting for it in the place this is used in your codebase, an error will pop and the dev will be forced to adapt the function to make it compatible with the typing.



```ts:item-size-calc.ts

type SizeOptions = 's' | 'm' | 'l' | 'xl' | 'xxl'


function getSizePriceVariant(size : SizeOptions) {
	 if (size === 's' || size === 'm') {
    	return 1;
    } else if (size === 'l' || size === 'xl') {
    	return 1.2;
    }
    
    // This code should be unreachable
    const neverHappens: never = size; // Type 'string'  is not assignable to type 'never'
    return neverHappens;
}
```


---

Here you go, you now know how to protect your code from situations like this using TypeScript and leverage 'never' to have red flags raised in your code whenever you, or someone else, does a modification and forgets to do exhaustive checking somewhere else in the code.

Exhaustive checking in TypeScript using 'never' type

  
    
    
*Hello, I'm Vasili and I've been working as a web developer for the last 7 years.* 
I was working as a waiter on a 7-day basis, but that changed 7 years ago.  I've always been good with using PCs and doing stuff with them. But I never thought my hobby could also be my job because I always thought something many people are thinking right now.

*If you want to work as a programmer / web developer, you HAVE to have university degrees*  
Well guess what ? That might have been the case 20 years ago, but NOT ANYMORE

If people like me, have followed this path and managed to get a job in the industry, that means that you can also do it as long as you persist and focus on it.
To help you, I will share with you how I learned what I know and I really hope that it helps you.
##### Please note : I am **NOT** affiliated with any of the following websites / youtube channels.
---
### Basics
These are the really basic stuff you need to know. Without them, you will not be able to do anything at all. For me, it was 6 full months of learning through websites and youtube videos but it might take longer for some people. The goal is to build habits and to be learning something no matter how big or small...
Here is a list of the main websites / youtube channels that helped me a lot during this phase.
- <UnderlineLink href='https://www.freecodecamp.org/'> FreeCodeCamp</UnderlineLink> : If you follow frecodecamp's Curriculum, you will have pretty solid foundations to start your career as a web developer.

-  <UnderlineLink href='https://www.youtube.com/channel/UCW5YeuERMmlnqo4oq8vwUpg'> The Net Ninja's Youtube channel</UnderlineLink> : I used this channel, alongside FreeCodeCamp because NetNinja has the right combination of explaining and teaching by example.  
  
    
Congratulations ! You now have what it takes to land a job for junior roles. Find a job and get more exposure to JavaScript.

---

### Tips on growing and learning more
After you know the basics, you have to keep experimenting. Try to recreate existing websites / applications. You will gain enough experience to start having a better view of what is happening.  I started making clones of small projects and once I was more confident, I moved on to learning new concepts / frameworks. TypeScript, Node, Server Side Rendering with NEXTJS, Redux, UI libraries, PHP, Symfony, you name it. 

The best way to learn at this stage, is by being exposed to JavaScript.

---

There will be bad days, programming is hard. Why would companies pay so much money to get developers if it were easy?  

The key here is **CONSISTENCY**.. Learn the basics, land your first job and keep learning. You don't need to be at the top 5% to get a job, but you HAVE to learn something small every day. Make it your goal to keep learning. 

You will see that there is **ALWAYS** something new to learn.. that's part of a programmer's career. You have to stay up to date and keep up with the evolution of your tech stack. You will experience imposters' syndrome. You will be stuck on a bug/problem for hours. Your skills will improve over time, but even people with decades of programming experience use google, reddit and stack overflow DAILY to find information and get the help they need to complete their objectives.
  

Good luck,  and remember. 
**It's hard, but it's well worth it.**

