
One of the most important things in programming is to clearly express your intent.

With release of ES6 we got two new keywords to define identifiers for our values: `let` and `const`.

Before that we had only `var` in our toolbelt. And in my opinion using `let` and `const` instead allows you to write more clear, eloquent and expressive code.

Simply speaking `let` allows you to define the identifier which value can be changed in the future, and `const` defines the one that is unchangeable.

Now let's figure out how it all works.

## Using `var`

In Javascript `var` declares new variable:

```js
var someVariable;

console.log(someVariable)
// undefined
```

Initially it's value will be `undefined`.

After you've declared new variable you can assign it new value.

```js
var someVariable;
someVariable = 1;

console.log(someVariable);
// 1
```

You can also combine those two steps and assign variable it's initial value while declaring it:

```js
var someVariable = 1;

console.log(someVariable);
// 1
```

You can declare variables in different **scopes**. In Javascript `var` can have on of two types of scope: **global** or **function** scope.

If you declare variable inside some functions body - it will only be visible inside this function and also functions declared inside of it. This is **function scope**.

Otherwise if you declare variable outside of any function - it will have **global** scope. And will be visible in all the functions you will use.

Another important thing about `var` in Javascript is that you can access it before it is declared. It is possible because of the process called **hoisting**.

That means that variable declarations are moved to the top of their **scope** when Javascript is being executed.

```js
console.log(myName);
// undefined
var myName = "Maksim";
```

In this example `console.log` will output `undefined`. It happened because the declaration of `myName` was moved to the top.

So this code is equivalent:

```js
var myName;
console.log(myName);
myName = "Maksim";
```

It's important to note that only variable declaration is moved to the top, not value assignment.

Ok, now you know about the **scopes** and **hoisting**, let's move on.

## Using `let`

`let` is a block scoped version of `var`. That means that it's visibility will be litimed to block, statement or expression where it was defined and all the inner blocks.

So if you declare a variable using `let` inside a `for` loop - it will be visible only inside this `for` loop block.

```js
for(let i = 0; i < 100; i++){
    console.log(i)
    // Here it will output all numbers from 0 to 99 
}

console.log(i)
// Here you'll get "ReferenceError: i is not defined"
```

Contrary to that `var` would be visible outside as well:

```js
for(var i = 0; i < 100; i++){
    console.log(i)
    // Here it will output all numbers from 0 to 99 
}

console.log(i)
// 99
```

And I think it's more desirable behavior. I can't really think of an example where you would want to have access to that `i` variable outside of the `for` loop.

In fact I think that the behavior of `var` in this case is even more bug prone. Because it allows the unwanted use of previously defined variables and can lead to confusion.

Also variables declared with `let` don't get **hoisted**.

```js
console.log(myName);
// Here you'll get "ReferenceError: can't access lexical declaration `myName' before initialization"
let myName = "Maksim";
```

And again, I can't come up with an example where you would really want to have the variable **hoisted**.

So in modern environments `let` seems to be a better, more controlled alternative for `var`. And if you need an identifier which value you can change - `let` is a preferred option.

## Using `const`

`const` has the same differences from `var` as `let` does, and on top of that, after it's value is defined - it can't be re-assigned.

It's important to note that value still can be changed:

```js
const dragon = {name: "Ancalagon the Black"}
dragon.name = "Glaurung" // This is valid

dragon = {name: "Glaurung"} // This is invalid
```

## Recap

So as a recap `let` is **non-hoisted**, **block-scoped** version of `var`. And `const` is also **non-reassignable** on top of that.

In my code I prefer to use `const` whenever possible. This allows me to signalize to myself and other developers that certain variable is not meant to change.

I don't use `for` loops often, when I work with arrays I prefer to use `map`. But when I do - I use `let`.

So my recommendation is to never use `var` and prefer `const` and `let` instead, as they provide more context to develope and act more predictably.

What Is The Difference Between Let, Const and Var In Javascript


Sometimes you might want to have a link to an item inside your markdown document. It can pe especially useful when you create table of contents for your document.

The most common way to do this is to provide a named anchor for the section you want to link to. For example let's say you can add anchor to your section header:

```md
<a name="section-header"></a>
## Section Header
```

You can also put this anchor inside your header:

```md
## <a name="section-header"></a> Section Header
```

## Github Markdown

Github automatically generates names for headers.

For example for `# Header Title` Github will generate the following code:

```html
<h1><a id="user-content-header-title" class="anchor" aria-hidden="true" href="#header-title">Header Title</a></h1>
```

So you'll be able to reference that header using following link:

```html
<a href="user-content-header-title">Go to header title</a>
```

How To Add Named Anchor In Markdown


ReactJS provides a bunch of methods that are executed during different stages of components life.

Those are called **lifecycle methods**.

> Lifecycle methods are only available for class based components. For functional components react provides [hooks](https://reactjs.org/docs/hooks-intro.html).

Here is a great diagram by Dan Abramov showing when each of them is being executed.

![lifecycle methods](lifecycle_methods.jpg)

Let's go through this diagram.

Horizontally it is split into three main stages:

* [Mounting](#mounting)
* [Updating](#updating)
* [Unmounting](#unmounting)

<a name="mounting"></a>
## Mounting

This is first stage each component goes through. During this stage component gets created and then mounted to the DOM.

First method that is being executed during this stage is `constructor`.

`constructor` is being called only once during components life. 

It the place where you set the initial state of your component or `bind` your event listeners.

> If you don’t initialize state and you don’t bind methods, you don’t need to implement a constructor for your React component.

Constructor is the only place where you can and should assign `this.state` directly. In all other methods, you have to use `this.setState()`.

```jsx
constructor(props) {
  super(props);
  // Don't call this.setState() here!
  this.state = { counter: 0 };
  this.handleClick = this.handleClick.bind(this);
}
```

> Avoid introducing any side-effects or subscriptions in the constructor. For those use cases, use `componentDidMount()` instead.

Don't copy `props` to `state`. It’s unnecessary (you can use `this.props.color` directly), and creates bugs (updates to the color `prop` won’t be reflected in the `state`).

`constructor` function is executed only once in component lifetime. So when the `prop` will be updated - it won't update the state.

Next method being executed is `getDerivedStateFromProps`.

This method is used very rarely. The only thing it does - it allows to calculate state based on passed props.

Next goes `render` method. And it's the only method that is required when you declare `class` based component.

In this method you define the layout of your component.

It is being called on every `state` or `props` update.

After `render` finishes its execution, React calls `componentDidMount`.

This method is being called right after `render` when component gets added to the DOM.

Usually it's used to fetch data from backend, or perform other side-effects.

It is a good place to do all the setup you couldn’t have done without the DOM.

* Make calls to external APIs or Javascript frameworks.
* Set timers using using `setTimeout` or `setInterval`.
* Add event listeners.
* Work with the DOM element you've rendered.

<a name="updating"></a>
## Updating

Next big stage is is updating. Methods of this stage get called every time `props` or `state` of the component get changed or `forceUpdate()` gets called.

First method that get's called during this stage is `getDerivedStateFromProps`.

As I already mentioned this method is rarely used.

Then `shouldComponentUpdate` is called, if the update was initiated by changed `props` or `state`.

This method allows you to prevent unnecessary re-renders. So it's used for optimization.

By default it returns `true`. You can return `false` if you want to prevent re-rendering in some cases.

This method is being called before every `render`, except the initial one.

If `shouldComponentUpdate` returned `true` - `render` method is executed.

Next method being called is `getSnapshotBeforeUpdate`. It is being executed right before the changes from Virtual DOM are to be reflected in the DOM.

This method is also used very rarely. Use it if you need to access some data in DOM before it gets overriden.

If you return value from this method it will be passed as third argument to `componentDidUpdate` that is being executed next.

`componentDidUpdate` is the last method that is being executed during update stage.

It is being called after all the changes to DOM are made. It accepts two arguments `prevProps` and `prevState` with values of `props` and `state` of that component before the update cycle has began.

Just like `componentDidMount` it is a good place to put your code that interacts with backend or other Javascript libraries.

If you make API calls make sure to compare current and previous props to avoid unnecessary network requests.

<a name="unmounting"></a>
## Unmounting

Last stage is unmounting and it has only one method - `componentWillUnmount`.

This method is being called right before the component is being removed from the DOM.

It is a good place to perfom the cleanup and remove your event listeners or timers that you might have added in `componentDidMount`.

> You should not call `setState()` in `componentWillUnmount()` because the component will never be re-rendered.

Now if you take a look at the vertical axis you'll see two phases.

First goes **rendering phase**. It is marked by gray background. It is pure and has no side effects. May be paused, aborted or restarted by React.

You shouldn't put any code with side effects inside methods of this phase.

For example you shouldn't make API calls or add event listeners there.

Rendering phase is completed after `render` methods of all the updated components get executed.

Just before **commit phase** when react updates the DOM React calls `getSnapshotBeforeUpdate`, so you can save some data from DOM before it gets overriden.

During this phase React calls one of three methods:

* `componentDidMount` - if it was mounting stage for that component.
* `componenDidUpdate` - if it was one of the supsequent updates.
* `componentWillUnmount` - is called before component is removed from DOM
