
In this post, we will get through what CORS is, why we have it and what is the meaning of CORS.

## What is CORS ?

Cross-Origin Resource Sharing (CORS) is an HTTP-header-based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources. CORS also relies on a mechanism by which browsers make a "preflight" request to the server hosting the cross-origin resource, in order to check that the server will permit the actual request. In that preflight, the browser sends headers that indicate the HTTP method and headers that will be used in the actual request.

For example, if we try to fetch some data on example-b.com, and we are trying to fetch it from example-a.com, we would need to add permission on the example-b.com server for example-a.com to be able to get that data because it's disabled by default. We also have two types of requests on frontend:

### - **Simple**
### - **Preflight**
<br/>

**Simple** is a type of request that is used when we want to send certain HTTP Methods (GET, HEAD, POST) that don't require an additional request (OPTIONS) to be sent before our request to check if the request is allowed. If we add custom headers to our request then it is not a simple request anymore, now it's a preflight type of request. Here is an image of a simple request:

<div className='gif-container'>
  <img src='/simple-get-request.webp' />
  <p className='gif-credentials'>
    Animation by{' '}
    <a
      target='_blank'
      rel='noopener noreferrer'
      href='http://www.linkedin.com/in/fatima-abdel-monem-trtak-09a39012a'
    >
      Fatima Trtak
    </a>
  </p>
</div>

**Preflight** is a type of request that uses additional OPTIONS request that is sent before our request to verify with the server that it supports the HTTP Method that we are trying to send and it's safe to send the request. Some of the methods that are considered preflight are (DELETE, PATCH, PUT, ...). Here is an image of the request with preflight:

<div className='gif-container'>
  <img src='/preflight-get-request.webp' />
  <p className='gif-credentials'>
    Animation by{' '}
    <a
      target='_blank'
      rel='noopener noreferrer'
      href='http://www.linkedin.com/in/fatima-abdel-monem-trtak-09a39012a'
    >
      Fatima Trtak
    </a>
  </p>
</div>

In these two images above you could see a few of the headers that are used when working with CORS: **Access-Control-Allow-Origin**, **Access-Control-Request-Method** and
**Access-Control-Request-Headers**. We will talk about them later in this post what they are for.

> NOTE: We use CORS only for requests that are not on the same domain because when it's on the same domain we have control over it and there is less chance for security issues. So by default, we don't have CORS on the requests that are on the same domain. For example, if we have our frontend on the localhost:3000 and our backend localhost:5000, every request from frontend to backend will have CORS added, since it's treated as a separate domain. The way we handle that is using something like NGINX, and having an application running on one port 80, and filtering traffic that we get, so we send all the requests to localhost:80  and NGINX does the proxy where frontend goes on frontend port, and backend goes on backend port, and that way we don't have CORS since we host everything on one place and browser doesn't complain about CORS.

## How to handle CORS issue

We all encountered the CORS during our programming development and probably just found the solution on the internet and just added it to our project without thinking too much about it as long as it works. But generally, we should understand what are we adding to the project so it doesn't introduce unexpected bugs. CORS is a big part of web development and should be understood by programmers. It's not hard to learn about it, but still, we add options that are not necessary for CORS to work because we just copy the values of the internet. As most of us did, we went on the internet and found a solution similar to this and added it to our code:

```js
res.setHeader("Access-Control-Allow-Origin", "http://localhost:3000");
res.setHeader(
  "Access-Control-Allow-Methods",
  "GET, POST, OPTIONS, PUT, PATCH, DELETE"
);
res.setHeader("Access-Control-Allow-Headers", "X-Something,content-type");
res.setHeader("Access-Control-Allow-Credentials", true);
```

This is a usual answer for the CORS issue, where we copy and paste it, even if our server has only GET and POST, we add PUT, PATCH, and DELETE Methods to the server without a reason. Access-Control-Allow-Credentials: true, means that we want to include credentials with the request and that both client that sends the request adding credential: true, and the server that responds with header Access-Control-Allow-Credentials are accepting credentials to be used when making requests. Credentials can be cookies or authorization headers or TLS client certificates. If we add **credentials** to our request we will notify the browser that we agree to send the credentials with the request and it will add preflight request that will check if server also has it enabled so we can include it in the request. The browser automatically adds cookies from that domain that's making a request in the request, and if the server responds with Access-Control-Allow-Credentials: true, we will get our response in the Javascript code, if not browser will reject the response. Simple GET requests don't have the preflight check, but the browser checks if we sent **credentials: true** and if the server responded with **Access-Control-Allow-Credentials: true** then we get the response in our Javascript code, if we don't have these headers then the browser just ignores the response from the server.

And as you can see we send many headers from servers without even needing them, if we don't have credentials with requests than we don't need **Access-Control-Allow-Credentials**, and if we don't have certain methods we should remove them from **Access-Control-Allow-Methods**, so our code can contain only what we actually need to work.

Now that we saw an example where we copy the solution from the internet, let's look at how we can solve this without searching for a ready solution, but make a solution ourselves and have an understating of what it does.

The first header that we should look into is Access-Control-Allow-Origin, then Access-Control-Allow-Headers, Access-Control-Allow-Methods, and Access-Control-Allow-Credentials depending if you have authorization on your server.

**Access-Control-Allow-Origin**

This controls on the server who can actually request and get our data, and if we don't have this header set no one will get it and the browser will throw a CORS error.
The first value that we can set and is a preferable option for 98% of cases is the wildcard _*_.
When we set _Access-Control-Allow-Origin: *_, we tell the browser that anyone can access our data and get the response. Usually, data that we make is globally available so this makes that possible. The next option we have is to set the list of domains that can access our data. For example, if we set _Access-Control-Allow-Origin: localhost:3000_, this means that only localhost:3000 can access the data on that server and no one else, this is good for companies that want only communication with certain domains for added security protection.

**Access-Control-Allow-Headers**

Here we add list of headers that our server excepts and supports, for example if we have some authentication "x-key" that we except on our backend we add it in this list so when it's sent from frontend our server can respond that it's ok to send this header. If we have default headers, we can skip this header and browser will handle it.

**Access-Control-Allow-Methods**

Here we tell the client that sent the request which methods we support, so if they send something we don't support it will throw a CORS error. We should add only the methods we support so it is easy to follow what's going on. Don't add all of them just in case you need them one day.

**Access-Control-Allow-Credentials**

We already covered this header above but basically, we use this when we want to send credentials to the server. Cookies, authorization headers, or TLS client certificates.
We only need it when we are using credentials, in any other case we can leave it out since it's false by default.

These headers are usually the ones we need to enable CORS and make those requests work as planned. In case you have different requirements then you can go and research about it more, best place to start is [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) where you can find almost all the information you need.

## Conclusion

Now you should have a better understating of CORS and how to deal with it, we don't need to find and copy a solution because we can make our own. If you find this interesting topic and it helped you share it with others so they can also learn about this topic.


What about CORS?


## What is code splitting ?

**Code splitting** is separating our bundled code into smaller chunks of code so we can download and use only the parts of code we need.
In React and Javascript frameworks in general, all the code is bundled in one large file. And this makes it easier to add it to the HTML using only one link. This also reduces servers call, and in theory, it should speed up the page loads and lower traffic for that page. But after we keep working on the app, we keep on adding files to our project. And adding more to our project makes that one Javascript file larger and larger, and that gets it slower and slower. Initially, one file was great, but after we keep adding we get it slower, so now we need to find a way to improve our page speed and that is where **Code splitting** comes into play.

## Why do we need code splitting ?

We use **Code splitting** to separate code and dependencies in multiple files so we can only use code that we need at that time. When you think about it we don't need to use all components or files at the same time, we have multiple pages, we have multiple components and we download them all when we open our application, even if the user doesn't visit **admin** pages, or maybe **report** pages we still download them with that one Javascript file. So when the application gets to a point of slowing down, we should start considering code splitting.

We can dynamically import components that we don't need at a certain time, so when we open the home page, we only download components and code that we need for the home page, which means that we don't have to download everything just to show few of them.

> **NOTE:** Multiple studies have shown that pages with lower response times have better impression on the user, and they
> are more likely to come back again [Studies link](https://www.hobo-web.co.uk/your-website-design-should-load-in-4-seconds/)

## How can we start code splitting ?

If we use create-react-app, Next.js or Gatsby, or similar tools, we have a code-splitting setup already using Webpack. If you are using some custom tool, or you created your own, you can add code splitting yourself and add it to your project. Here is a [link](https://webpack.js.org/guides/code-splitting/) of setting up code splitting and lazy loading in your app using Webpack. But it can be set up with other bundlers like [Rollup](https://rollupjs.org/guide/en/#code-splitting), [Browersify](https://github.com/browserify/factor-bundle) or [Parcel](https://parceljs.org/code_splitting.html) or any other bundler.

We have few ways we can add code splitting to our React application:

**Dynamic import()**

Dynamic import has been added to the Javascript in ES6, and we can natively start code splitting our Javascript code. With dynamic imports it's quite easy:

Before:

```js App.js
import { Header } from './Header';

<Header />;
```

After:

```jsx App.js
import React, { useState } from 'react';

export default function App() {
  const [Header, setHeader] = useState(null);

  React.useEffect(() => {
    import('./Header')
      .then((component) => {
        setHeader({ Component: component.default });
      })
      .catch((err) => {
        // Handle failure
      });
  }, []);

  return <div className='App'>{Header ? <Header.Component /> : null}</div>;
}
```

Or with async / await:

```jsx App.js
import React, { useState } from 'react';

export default function App() {
  const [Header, setHeader] = useState(null);

  React.useEffect(() => {
    (async () => {
      const component = await import('./Header');
      setHeader({ Component: component.default });
    })();
  }, []);

  return <div className='App'>{Header ? <Header.Component /> : null}</div>;
}
```

Or if you want to use it with Named Exports instead of Default Export as in the example above, you can do it like this:

```jsx App.js
import React, { useState } from 'react';

export default function App() {
  const [Header, setHeader] = useState(null);

  React.useEffect(() => {
    import('./Header')
      .then(({ Header }) => {
        setHeader({ Component: Header });
      })
      .catch((err) => {
        // Handle failure
      });
  }, []);

  return <div className='App'>{Header ? <Header.Component /> : null}</div>;
}
```

Or with async / await:

```jsx App.js
import React, { useState } from 'react';

export default function App() {
  const [Header, setHeader] = useState(null);

  React.useEffect(() => {
    (async () => {
      const { Header } = await import('./Header');
      console.log(Header);
      setHeader({ Component: Header });
    })();
  }, []);

  return <div className='App'>{Header ? <Header.Component /> : null}</div>;
}
```

As you can see it's easy, but the syntax is a bit weird. We have a second way of code splitting in React.

## React.lazy() and React.Suspense

[React v16.6.0](https://reactjs.org/blog/2018/10/23/react-v-16-6.html) introduced a way to do **code-splitting** in React, they added two features React.lazy() and React.Suspense that enables us to use code splitting directly in React.

- **React.lazy()**

> **Note:** At the time this blog is written, React.lazy() and Suspense are not available for server-side rendering, but they should be in the future. For now, we can use
> [Loadable Components](https://github.com/gregberge/loadable-components) to use code-splitting for server-side rendering.

The React.lazy enables us to dynamically import components, for example:

Before:

```jsx App.js
import React from 'react';
import Header from './Header';

export default function App() {
  return (
    <div className='App'>
      <Header />
    </div>
  );
}
```

After:

```jsx App.js
import React, { lazy, Suspense } from 'react';
const Header = lazy(() => import('./Header'));

export default function App() {
  return (
    <div className='App'>
      <Suspense fallback={<div>Loading stuff...</div>}>
        <Header />
      </Suspense>
    </div>
  );
}
```

Here you can see how much easier this is than the Dynamic import, we just import lazy and Suspense from React and use them to lazy import components then use Suspense to display some fallback value while we wait for our component. Don't forget to wrap the lazy imported component in Suspense, since React expects to have a fallback while we wait. We can also use single Suspense to wrap multiple lazily imported components:

```jsx App.js
import React, { lazy, Suspense } from 'react';
const Header = lazy(() => import('./Header'));
const Footer = lazy(() => import('./Footer'));

export default function App() {
  return (
    <div className='App'>
      <Suspense fallback={<div>Loading stuff...</div>}>
        <Header />
        <Footer />
      </Suspense>
    </div>
  );
}
```

> **NOTE:** ⚠️ At the time this blog was written, React.lazy only supports **Default Exports**, and if you want to use **Named Exports**
> you can create an intermediate module that can reexport it as default. This ensures that tree shaking keeps working and that you don’t pull in unused components.

```jsx Header.jsx
import React from 'react';

export const Header = () => {
  return <div>Header</div>;
};
```

```jsx ExportDefault.jsx
export { Header as default } from './Header';
```

```jsx App.jsx
import React, { lazy, Suspense } from 'react';
const Header = lazy(() => import('./ExportDefault'));
const Footer = lazy(() => import('./Footer'));

export default function App() {
  return (
    <div className='App'>
      <Suspense fallback={<div>Loading stuff...</div>}>
        <Header />
        <Footer />
      </Suspense>
    </div>
  );
}
```

This gets a bit annoying that you need to create an additional component just to export it, in my opinion, it's better to use default export for components that are lazily loaded.

- **Error boundaries**

When using lazy() and Suspense there is a possibility that the module fails to load due to some network issues or something else and it will throw an error. We have to handle those errors so our user experience doesn't suffer. To prevent that we use ErrorBoundaries that wraps our Suspense and lazy, and handles errors that might happen while loading components lazily. If you want to create your ErrorBounary you can visit React official documentation and use examples there, but at this time there is no equivalent of ErrorBoundary written using Hooks, so it will have to be written with class components. I will use a library called "[react-error-bounndary](https://www.npmjs.com/package/react-error-boundary)", since I don't like working with classes 😅.

```jsx App.js
import React, { lazy, Suspense } from 'react';
import { ErrorBoundary } from 'react-error-boundary';
const Header = lazy(() => import('./ExportDefault'));
const Footer = lazy(() => import('./Footer'));

export default function App() {
  function ErrorFallback({ error, resetErrorBoundary }) {
    return (
      <div role='alert'>
        <p>Something went wrong:</p>
        <pre>{error.message}</pre>
        <button onClick={resetErrorBoundary}>Try again</button>
      </div>
    );
  }

  return (
    <div className='App'>
      <ErrorBoundary FallbackComponent={ErrorFallback}>
        <Suspense fallback={<div>Loading stuff...</div>}>
          <Header />
          <Footer />
        </Suspense>
      </ErrorBoundary>
    </div>
  );
}
```

Much easier than creating your own using classes, but it will change when they add equivalent to Hooks.

## Where to use code splitting 🤔

One of the ways that you should probably use code splitting is on your routes. If you think about it, many users don't visit all of our routes when they visit our application, so why slow down the app and increase waiting time just to download code that they probably won't need. We can determine using some statistic tools what pages are most used and users are most likely to visit then they enter our app, and based on that create code splitting for them.

```jsx App.js
import React, { lazy, Suspense } from 'react';
import { BrowserRouter as Router, Route, Switch } from 'react-router-dom';
const Home = lazy(() => import('./Home'));
const Reports = lazy(() => import('./Reports'));

export default function App() {
  return (
    <div className='App'>
      <Router>
        <Suspense fallback={<div>Loading stuff...</div>}>
          <Switch>
            <Route exact path='/' component={Home} />
            <Route path='/reports' component={Reports} />
          </Switch>
        </Suspense>
      </Router>
    </div>
  );
}
```

This is how Javascript code looks before we use code splitting:

```text
main.chunk.js
main.12381831283.hot-update.js
bundle.js
0.chunk.js
```

And this is how it looks after we add code splitting:

```text
main.chunk.js
main.12381831283.hot-update.js
bundle.js
0.chunk.js
2.chunk.js
```

And you can see here that we have an additional file **2.chunk.js**, that was created when we opened for example /home route, and we got only Home.js and not the other components.

If you want to check how files look in your app before and after you do code splitting, you can open Inspect in Chrome and then go to the Network tab, and select JS in filters so you get the only list of Javascript files. One more useful thing in chrome is the Coverage tab that helps us see all Javascript files that are downloaded and what code percentage of those files are used. You can open Inspect in Chrome and press Ctrl+Shift+P and type **Show Coverage** and press enter, and it should show you the coverage tab. Here is a [link](https://developer.chrome.com/docs/devtools/coverage/) of how to use that Coverage tab to see unused code, I will not go into it since this post is about code splitting.

One more case where we could use code splitting is in the application that has admin and regular users. For example we login in to our application as a normal user, and when we log in we get all the code for our app, including the admin panel that we don't have access to. So we download all that code and slow downloading and we want to use it at any point since we don't have access. This is a great way to introduce code splitting to download only part that we can use and access, and improve the speed of our app and also don't allow curios people to sniff and look around our admin panel code 🧐

> If you want to test the speed of your application there is an amazing tool in Chrome called Lighthouse, you can access it by opening Inspect in Chrome and then going
> to the Lighthouse tab. There is an option to test many things for your app on Desktop and Mobile.

> **NOTE:** when testing speeds of your app it's important to know that a development app is much slower than a production app since many bundling features are not used
> in development app to improve debugging and speed up development since we don't have to do additional stuff like [minification](https://webpack.js.org/guides/production/#minification), [uglification](https://webpack.js.org/migrate/3/#uglifyjsplugin-sourcemap), etc.

## Conclusion

To Recap, we went through what is code-splitting, how to use it, and example where we might use it. This should be a good start for you to start adding code splitting to your application and see those loading times improving. If you find this post informational and useful, please share it with others so they can benefit from it. Also, don't stop at this post, read more about it, follow the links I provided in the post and also visit the official documentation of [React](https://reactjs.org/docs/code-splitting.html) for more information.


Code splitting in React


There are many answers about this topic floating around the internet, but many of them make it complicated for some reason when explaining. This shouldn't be that hard to understand so I'll try to fill the gaps for this topic. I've also noticed that images can help when trying to understand stuff, so I'll try to use simple examples to explain **debounce** and **throttle** in javascript.

## What is **debounce**? ⚽

It is a programming practice that we use to ensure that certain tasks don't fire too often. What I mean by that is that we forbid firing certain actions one right after another.
And how that works is that you set a delay on those actions that need to be executed, and every time you fire that action new delay is created, and the previous action is removed so we don't fire it multiple times.

Here is the image that explains debouncing:

![alt](/js-debounce.png)

<div className='gif-container'>
  <p className='gif-credentials'>
    Drawing by{' '}
    <a
      target='_blank'
      rel='noopener noreferrer'
      href='http://www.linkedin.com/in/fatima-abdel-monem-trtak-09a39012a'
    >
      Fatima Trtak
    </a>
  </p>
</div>

As you can see, if we click on the button many times, we will not execute the action that the button is firing until we stop clicking on it, and the delay we set has passed.
When delay passes, we execute the action. Here is how we can write that in Javascript:

```js debounce.js
const debounce = (fn, delay) => {
  let timeoutID;

  return function (...args) {
    if (timeoutID) {
      clearTimeout(timeoutID);
    }

    timeoutID = setTimeout(() => {
      fn(...args);
    }, delay);
  };
};

document.getElementById('btn').addEventListener(
  'click',
  debounce((e) => {
    console.count('click');
  }, 1000)
);
```

```html index.html
<button id="btn">SUBMIT</button>
```

Here we have event listener on the button with id "_btn_". Every time we click on that button, we will fire an action that will write in the console the word "click". When we
click on the button, we call a function to debounce and pass two parameters. The first one is a function that we will execute, and the second one is the delay that we will wait after the last time a button is pressed. In the debounce function every time it's called we will create a variable timeoutID that will hold the value to the _setTimeout_.

We need that reference because every time we click that button new _setTimeout_ will be created, and we need it to delete the previous _setTimeout_ so not all of them get executed but only the last one.
Next, we return the function that is executed on every click. Inside we first check if we already have a _setTimeout_ created, if we do we will first delete that one, then
we will add to **timeoutID** new _setTimeout_ that will wait for the delay to pass or if we click again will be deleted and a new one created.

After the delay has passed, we will execute the function that we passed to debounce, in our case it's **console.count('click')**.
Here is a component below that you can play with and check what happens with and without debouncing enabled, click on both buttons and see the counter value changing:

<DebounceBtnExample />

As you can see, we have much fewer clicks on the debounced button than on the normal one. This can be useful in an application where you maybe have a submit button for paying websites, and the user by mistake clicks twice in a row, and it is not handled properly, it can send two requests and maybe take the double value of what was displayed. Debounce is especially useful
when it comes to search, if you have implemented a reactive search bar where it should respond with data while you are typing, this can help you send only one request when the user has finished typing instead of every keypress.

## What is **throttle** ? 🏍

Unlike debounce, the throttle is firing event between intervals, so when we click on a button for the first time it will execute the action, and if we keep clicking on that button, it will not fire event until time interval has passed, and if you keep clicking it will fire every time interval it completes. Here is an image representing that behavior:

![alt](/js-throttle.png)

<div className='gif-container'>
  <p className='gif-credentials'>
    Drawing by{' '}
    <a
      target='_blank'
      rel='noopener noreferrer'
      href='http://www.linkedin.com/in/fatima-abdel-monem-trtak-09a39012a'
    >
      Fatima Trtak
    </a>
  </p>
</div>

You can see on this image (hopefully 😊) that we click on a button and it fires an event, then we keep clicking on it and nothing happens until the delay time has passed and it fires again,
and if we are still stubborn and keep clicking the button, it will keep firing event every time the delay is finished. Here is an example of how we can do it in Javascript:

```js throttle.js
const throttle = (fn, delay) => {
  let last = 0;
  return (...args) => {
    const now = new Date();
    if (now - last < delay) {
      return;
    }
    last = now;
    return fn(...args);
  };
};

document.getElementById('btn').addEventListener(
  'click',
  throttle((e) => {
    console.count('click');
  }, 2000)
);
```

```html index.html
<button id="btn">SUBMIT</button>
```

As with debouncing example, we have a button in Html with id "_btn_", and a throttle function that will be called on every click. Then we create a variable where we will hold the value of the last executed action. In the next step, we send the function back that will be executed every time we click the button, and inside we check if time passed from the first and last click is less than our delay. If the time is less than delay then we do nothing, but if it is not, we assign a new time to the last variable so we can compare it with the next clicks then our callback function (**console.count('click')**) is returned and executed, and if we keep clicking that button we will always wait for that delay, and after it's passed we execute again. The same goes for the search, if we keep typing some text it will execute every time delay is passed from the first execution. Here is an
example of throttle and normal button and search bar, try it and see what is going on:

<ThrottleBtnExample />

Hope you tried these examples above, and saw the behavior of the throttling, and could understand how it's different from the debouncing. Throttling is not used in
practice as much as debouncing but is good to know and but who knows, maybe it's a better option for what you need on your project.

## Conclusion

It wasn't that hard, wasn't it? It's a bit confusing but with some drawings and interactive examples, it gets easier to understand. Debouncing is used a lot and now it can be
used even more 😉. To recap, we went through what are debouncing and throttling in Javascript, where it can be used, and how it works. If you are React developer you'll be
glad to hear that I'll also plan to create a post about debouncing and throttling in React using hooks, which is a bit different compared to plain Javascript. Also if you can
it would be nice to share the post, so others can benefit from this.


Javascript Debounce and Throttle Explained


_What are Event Bubbling, Event Capturing and Event Propagation and how to use them_

## Event Propagation

**Event Propagation** is a behavior of events in Javascript. Propagation means spreading in English dictionary, and that's exactly what **Event Propagation**
is doing, it's spreading events through elements above itself in a hierarchy. That spreading happens in three phases, the first phase is **Capturing**, the second is **Target** and the last one is **Bubbling**.
We will go into detail about what these are.
Capturing is when we go from the top of our window object to the target, which in our case is the "td" element then we go from that target back to
the top of our window object. I should also mention that if you need to stop the propagation of the event, and want it to fire only on the current element, you can use **stopPropagation()**. This
will stop the event on the current element we clicked and won't spread on the higher elements.

> NOTE: Very important to know that not all events have propagation on them, for example, **blur**, **focus** and **scroll** don't have propagations. They don't spread to parents,
> grandparents, etc. Also, **Event Propagation** is sometimes referred to as **Event Delegation** which is the same, just has a different name.

Below is an animation showing Event Propagation using bubbling:

<div className='gif-container'>
  <img src='/bubbling-normal.webp' />
  <p className='gif-credentials'>
    Animation by{' '}
    <a
      target='_blank'
      rel='noopener noreferrer'
      href='http://www.linkedin.com/in/fatima-abdel-monem-trtak-09a39012a'
    >
      Fatima Trtak
    </a>
  </p>
</div>

Here we have a "div" element and inside that element, we have a table with some rows. And those rows have a checkbox, if we click on that box, we will start propagations from that element.
And any element that has event on itself will be executed, so it goes _checkbox > td > tr > table > div > ... > window_. This can be useful if we want to create an event
on every row in the table, but don't want to manually add events for all of them individually, we can create an event on "table" and check which row was clicked and apply actions
to that row. Maybe for every row that is clicked, we want to add a class "active", that changes the color to gray. So it can reduce all that writing to just one event, and
writing less code is best 😎 .

> NOTE: If you maybe heard about **preventDefault()** and thought why not use that to stop propagation, well this method is used only for an element that has default behavior,
> like form, but if we are clicking on div, we don't have any default behavior so we use **stopPropagation()** to stop propagating.

## Event Bubbling

This is the default behavior of events in the modern browser so I'll cover it first. **Event Bubbling** is behavior that executes all the events from the target to the top of the window,
except ones we said that don't propagate (blur, focus, scroll). So if we click on the last child in the document, it will **bubble** to every parent and execute their events.
For example, we click on the table checkbox, which will cause that checkbox to fire an event (if it has any) and then go to checkbox parent and try to fire an event, and then go up the
hierarchy one by one and try to execute all the events along the way. We have an animation here showing that behavior:

<div className='gif-container'>
  <img src='/bubbling-tree.webp' />
  <p className='gif-credentials'>
    Animation by{' '}
    <a
      target='_blank'
      rel='noopener noreferrer'
      href='http://www.linkedin.com/in/fatima-abdel-monem-trtak-09a39012a'
    >
      Fatima Trtak
    </a>
  </p>
</div>

As you can see click on the checkbox on the bottom is causing bubbling of events all the way to the top. So if any element had an event, for example, a table, it would fire that one
also, and even at Window, it would fire if there are any events. This behavior can be stopped by using **stopPropagation()**, and the event will be only executed on the
checkbox and nowhere else. This can be used if you have a checkbox, and maybe delete or edit on the same row and also an event on the row itself like onClick that opens
different views with values from that row. If you don't use stop propagation, it would fire edit and also went to a different view, so that edit would be kinda ignored and
useless.

```html Bubbling.html 🎈
<div>
  div
  <table>
    <tr>
      <th>table</th>
    </tr>

    <tr>
      <td id="checkbox">
        <input type="checkbox" />
      </td>
      <td>input</td>
    </tr>
    <tr>
      <td id="checkbox">
        <input type="checkbox" />
      </td>
      <td>input</td>
    </tr>
    <tr>
      <td id="checkbox">
        <input type="checkbox" />
      </td>
      <td>input</td>
    </tr>
  </table>
</div>

<script>
  function clicked() {
    alert(this.tagName);
  }

  var elems = document.querySelectorAll('div, table, input');
  for (let elem of elems) {
    elem.addEventListener('click', clicked);
  }
</script>
```

Here is code that you can copy and try for yourself. It quite simple, we have a _div_ and _table_ with _rows_ inside, we also create _click_ events on the div, table, and inputs.
We also have an example at the end that you can check to see how this code should look and behave.

## Event Capture

This one is quite similar to Bubbling but unlike Bubbling when we click on the checkbox in the row it would go from the top (Window) to that target checkbox, so the event on
the checkbox would be fired last instead of first like in Bubbling. This can be useful if you want to notify parents first and then execute children's events. Also, this
phase has to be enabled since Bubbling is the default behavior, and we can do this by adding a third property to _addEventListener("click", function(e){},**true**)_. This value
**true** is a value of **useCapture** which is false by default. Now that we set it to true we will have to capture behavior in our tree.

<div className='gif-container'>
  <img src='/capturing-tree.webp' />
  <p className='gif-credentials'>
    Animation by{' '}
    <a
      target='_blank'
      rel='noopener noreferrer'
      href='http://www.linkedin.com/in/fatima-abdel-monem-trtak-09a39012a'
    >
      Fatima Trtak
    </a>
  </p>
</div>

As you can see this is similar to the Bubbling but events are fired the other way around, here is a code snippet same as bubbling but added property for capturing events instead of bubbling:

```html Capturing.html 📷
<script>
  function clicked() {
    alert(this.tagName);
  }

  var elems = document.querySelectorAll('div, table, input');
  for (let elem of elems) {
    // We added third parameter 'true' to enable capturing
    elem.addEventListener('click', clicked, true);
  }
</script>
```

Here is also an example of how to stop event bubbling or capturing:

```html StopPropagation.html
<script>
  function clicked(e) {
    alert(this.tagName);
    //Prevent event propagation
    e.stopPropagation();
  }

  var elems = document.querySelectorAll('div, table, input');
  for (let elem of elems) {
    elem.addEventListener('click', clicked, true);
  }
</script>
```

Here is an example you can play with, use toggle to switch from "_bubbling_" to "_capturing_" and click on the elements, we have events on the checkbox, table, and div.

<EventPropagationExample />

## Conclusion

This was an interesting topic to write about, and I hope these events' behavior is clearer now. If you think that this post helped you understand this topic then, please share with others so they can also learn this.


What are Event Bubbling, Capturing and Propagation


_What you need to know about Git, and Git commands that you will use on daily basis_

As most people know, _git_ is a really big part of programming and is used everywhere and in every project. So learning the commands and how to use them
is important and useful. Every project you work on will use some kind of git: "Github", "GitLab", "BitBucket" or any of the other one. In this post, we will go
through what _git_ is, and what are some of the commands you will probably use daily.

> **NOTE** If you use some kind of GUI for git like "SourceTree", "Github Desktop" or maybe VSCode extension. Try using more of the console for git
> since that will help you understand what happens behind those button clicks, and will be useful in case you get stuck somewhere and need to figure out what happened

## What Git is?

Git is a type of version control system that makes it easier to track changes to the files. For example, if you edit some file, git can help you determine what exactly
changed, who changed the file, and why they changed it. If git is enabled in the project you are working on, it tracks the changes on the files you are working on and changing,
so later you can go and check what changes were made, on what files, and also who made those changes.

This can help you a lot in your project, if you made a mistake somewhere in code
you can go back in time and check every change and check what and where the issue happened. Just imagine the world 🌍 without git, and you made mistake in a project
that has many files and few people working on it, and a bug is found.

It would be quite hard to find the cause of the bug, when it was made, and also what else is affected
by it. That's why tools like git make our life much easier and less stressed 😄.

<div className='gif-container'>
  <iframe
    src='https://giphy.com/embed/susHG0bM68Poc2SAnI'
    className='giphy-embed'
    allowFullScreen
  ></iframe>

  <p className='gif-credentials'>
    <a
      target='_blank'
      rel='noopener noreferrer'
      href='https://giphy.com/gifs/susHG0bM68Poc2SAnI'
    >
      via GIPHY
    </a>
  </p>
</div>

When we initilize git in our project we get **local working directory**, which means all the changes to the files and commiting happens on our local machine, and we are the
only ones that can access these files. So in case something happens with your local computer, and you can't restore that computer you'll also loose all those changes
and everything your did on the project. Thats why tools like Github or GitLab or any other tool like this helps us save our work no matter what happens to our computer.
What they actuall do is create copy of our local git project and put them on the internet where we can access anytime we need it. Also we have options to make our projects
private and choose who can access them and work on them, in case we have multiple people working on project, or if you working on something yourself that is a secret 🔏
and dont wan't other to see it. That is called **remote working directory** and we have neat commands that make it quite easy to send our locally changed files to remote
location.

## Commands in Git 💻

> ## git add && git commit

One of the most used commands on a daily basis is **_git add_** and **_git commit_**, we use this to add changed files to staged changes, which means if we have mutiple
files changed in project, but only want to add few files to local repository we use **_git add_** and add them for staged changes and prepare for next step which is commiting.

```git
git add file.js
```

Using this command we add one or multiple files to staged changes and then we can go to the next step which is committing those files to a local repository. We also have a command to automatically
add all changed files in the project to the staged changes by using.

```git
git add .
```

Using this we can commit all the changed files and don't have to name them one by one. After we add files we can commit them by using this command:

```git
git commit -m "Commit message"
```

Then we commit our files to a repository with an appropriate message and can continue working on our project without fear we will lose something or remove something.
If we want to add all the files to staged changes and commit them without checking anything, we can use a shortcut that enables us to do that:

```git
git commit -am "Commit message"
```

> **NOTE:** Better option would be to add changed files to staged changes and verify that nothing is missing or maybe unwanted stuff is
> added. And after files are verified, commit them to the repository.

> ## git status && git log

The next thing that is used a lot is **git status** and **git log**, these two are used to check the status of the files. **git status** shows us which files are changed and which ones are
added to staged changes, and **git log** shows us our commit history. They are quite useful because they give you the possibility to check what changed, is it staged or not. Or to check
the history of commits, overview what happened with that branch.

```git
git status
```

Try this in your git console and see what happens, if you have modified any of the files they will show in the console, and maybe you can play around with **git add**
and see what changes.

```git
git log
```

When you execute this command **git log** you will see a list of all the commits on the current branch, all the commits have _commit id_ and _commit author_, also
there should be date and commit message that you've added. Also if you don't need all that information about commit, you can use a shorter version of _git log_ which
can give you a better overview, and more commits on the screen.

```git
git log --oneline
```

There are many variations for **git log** and other git commands, and the best place to check them all is the official documentation for [Git](https://git-scm.com/doc)
and [ProGit](https://git-scm.com/book/en/v2) book that is free, and goes much deeper than this post.
Definitely check it, and see what other options are there, maybe they are useful for your use case.

> ## git branch && git checkout

These commands are also used often, not as much as the ones above. We used them when we want to add a new feature or test something on our application, but don't want
to do that on the main code, so we don't break stuff, we do it on a different branch, that has the same files but on a separate place. This way we can do whatever we
want without fear of breaking stuff that works. This is also the reason that we have **main branch** that contains only stuff that is verified and works,
and we create separate branches to add new things and/or test things. So we use **git branch _branch-name_** to create a new branch with the name we gave it to it, and
if we want to check if it's created, we can use **git branch** and we will get the list of all branches we have on our local repository.

```git
git branch test-branch
```

```git
git branch
```

When we verify that branch is created, we use **git checkout _branch-name_** to enter that branch, and when we do that all the changes that are made will only be there,
and no other branch will be affected.

```git
git checkout test-branch
```

As with many git commands, we can use a shorter version of **git branch branch-name** and **git checkout branch-name** that can help users create a new branch, and automatically
go to that branch, that command is:

```git
git checkout -b test-branch
```

This will create a new branch named _test-branch_ and will do a checkout, so you don't have to manually do checkout. These short commands can save some time, and if you are
in a hurry, sometimes you forget to checkout branch after creating, and you start creating changes on the wrong branch (happened to me 😌).

> ## git merge && git stash

These two are not used that often, but very useful. For example, if we have some changed files in our repository, and maybe we have an error in some other branch,
but we are in the middle of work, you can't just **checkout** another branch because we might have some conflicts. We can use **git stash** to help us, what it does is save
the changes that we made on the current branch to the some place on the side so we can access it later when we need it. So we stash the changes, go to the other branch and
fix those issues, then come back to the branch where we stashed changes and apply those changes and continue where we left off. To stash changes we use:

```git
git stash
```

With this command, we created a stash file that we can apply later when we need it, or if we decide we don't need it we can just delete it. If we use this command, it
will create a list of stashed changes listed by index. When we want to check list of our stashed files, we can use this command to see them:

```git
git stash list
```

And if you want to apply changes you stashed, you have to use the index of changes you want,you can use **git stash list** to see all the stashed files, and
if you want a third stash we can apply those changes like this:

```git
git stash apply stash@{3}
```

Now we will get all the changes in our project that were in that stash, this is helpful when you need to jump between branches. The next command is **git merge**, and we
use this to combine branches. We usually combine our working branches with the main branch, after we finish them and test they work. The way we use it is that we go on a
branch that we need changes on, and type command and merge the branch that we need, sounds confusing but it's actually quite easy 😎

```git
git merge test-branch
```

So if we are on the _master_ branch and we execute this command, we will merge all the changes from the _test-branch_ branch to the master, and we will have everything on the
_master_ branch.

> ## git push && git pull

All the commands we talked about above are used on the local repository, which means we are the only ones that can see the project, work on it or do anything to it. But now we decided
to put our project on the Internet, so our colleagues or friends can work on the project with us, or maybe we want to make a backup in case something happens to our machine
and we lose the local repository. When we make changes and commits on our local repository and are ready to add that to the remote repository, we can use **git push** to
add those changes to the remote repository. We just execute it and git does its magic and puts everything on the remote repository, simple as that.

```git
git push
```

Now we made a backup of our changes and don't have to live in fear that we could lose stuff if the machine goes crazy one day

<div className='gif-container'>
  <iframe
    src='https://giphy.com/embed/xUPGcEliCc7bETyfO8'
    className='giphy-embed'
    allowFullScreen
  ></iframe>
  <p className='gif-credentials'>
    <a
      target='_blank'
      rel='noopener noreferrer'
      href='https://giphy.com/gifs/producthunt-cat-developer-xUPGcEliCc7bETyfO8'
    >
      via GIPHY
    </a>
  </p>
</div>

We use **git pull** to get the latest changes from our remote repository, so if someone works with us and added some new stuff that we need to use, we can execute this
command and get all the changes to the local repository.

```git
git push
```

Now we have all the changes in our local repository, and now we can keep working and use those files from the remote repository.

> **NOTE:** These are commands that are used quite often, it's good to know what they are, how they work, and how to use them,
> but don't stay on just these, visit the official documentation and ProGit book and add more knowledge to your skills

Some of the commands that are worth mentioning are **git reset** that we use to reset commits, so if we made some mistakes in commit maybe wrong files added or wrong title
or whatever, we use **git reset** to un-commit changes and fix them, then commit them again but with right values. **git rebase** is also a quite powerful command that has
many abilities, definitely read more about it in official documentation [git](https://git-scm.com/doc)

<br />
<br />

![alt](/git-flow.png)

<div className='gif-container'>
  <p className='gif-credentials'>
    Drawing by{' '}
    <a
      target='_blank'
      rel='noopener noreferrer'
      href='http://www.linkedin.com/in/fatima-abdel-monem-trtak-09a39012a'
    >
      Fatima Trtak
    </a>
  </p>
</div>

<br />
<br />

### Local repository

- **git add** (Add changed files to staged changes, and prepare them for committing)
- **git commit** (Add those changed files to the local repository)
- **git status** (Check which files are changed and which ones are in staged changes)
- **git log** (See the list of the commits on the branch)
- **git stash** (Stash changes when you need to switch branches and apply them later)
- **git merge** (Combine branches so you have files from other branches)
- **git branch** (Create branch and separate tasks in progress)
- **git checkout** (Go to the created branch)

### Remote repository

- **git pull** (Pull changes from a remote repository)
- **git push** (Push your local changes to the remote, and create a backup for them)

## Conclusion

We got through this long post, with a lot of useful knowledge gained. Now we have more confidence while working with git. We covered adding files and committing them
to a local repository, we also saw how to check what changed and what was committed. Also, we learned how to create branches that we use to separate work, and we learned
how to add projects and all changes to a remote repository. That means that we can share our project with others, that many people can work on the same project easily, and we
have a backup of our project in case we have problems with our machine.


What you need to know about Git


> **NOTE:** All these ES2021 features are available in most of the major browsers, others are in process of adding them.
> So you can try all these examples in any major browser, but I recommend Brave and Google Chrome

Before we start just to mention that even if these features are added to the browser for us to use, as of the day I'm writing this blog April 24, 2021, these features are not
added to [ECMAScript](https://tc39.es/ecma262/) and are not part of Javascript standard. Approval is scheduled for June 2021, and then they will become part of the standard.
If you want to see about these features or any new one, you can go to the official GitHub repository where these features get presented, discussed, and approved for the
addition to Javascript [TC39](https://github.com/tc39/proposals).

We have five new features in Javascript, and they are:

- **String.prototype.replaceAll()**
- **Promise.any()**
- **Logical Assignment Operators**
- **Numeric spearators**
- **WeakRefs**

## String.prototype.replaceAll()

The first one is **replaceAll()** that we can use to replace all instances in string. We already had **replace()** which does a similar thing but **replace()** only replaces
the first instance in a string and not all of them. The workaround for replacing all instances was by using regex. As we know regex is confusing, the syntax is kind of weird. Also, since it's not used that often we forget how to work with regex so we have to refresh our mind every time we need it, or just copy the solution without knowing why is written like
that (which is a bad practice, you should know what the stuff you are using is doing in code). So this addition is quite useful and we can replace instances in a string without needing to mess with regex. Here is an example of how you can use **replaceAll()**:

```js
const text = 'This text should be replaced with a different text';

const replaceFn = text.replace('text', 'name');

const replaceAllFn = text.replaceAll('text', 'name');

console.log(replaceFn);
// This name should be replaced with a different text

console.log(replaceAllFn);
// This name should be replaced with a different name
```

If you try this example above for yourself, you'll see that _replaceFn_ is only replacing the first instance of word _"text"_, but _replaceAllFn_ is replacing
all instances of word _"text"_. As you can see this new feature is nice and useful, no more messing with regex, at least for this use case 🎉.
If you want to check more about this feature you can go on the offical GitHub repository where these features are presented and discussed
[String.prototype.replaceAll()](https://github.com/tc39/proposal-string-replaceall).

## Promise.any()

The second was added to the Promise methods, and it receives a list of promises _Promise.any([first, second, third])_ and we wait for the first successful or all of them to fail. So if the _first_ promise is successful we abort others, but if first is a failure and _second_ one is successful then it gets aborted. The same goes
for if _first_ and _second_ are failures but the _third_ is successful. This is a kinda optimistic Promise that will not stop until one is successful or all of them fail. Now let me show you an example of how to use it, and how it's different from the other methods:

```js
// We use delay to simulate response from an API
const delay = () => Math.floor(Math.random() * 1000);

const first = new Promise((resolve, reject) => {
  setTimeout(() => resolve('First'), delay());
});

const second = new Promise((resolve, reject) => {
  setTimeout(() => resolve('Second'), delay());
});

const third = new Promise((resolve, reject) => {
  setTimeout(() => resolve('Third'), delay());
});

const promiseAny = async () => {
  try {
    const firstResponse = await Promise.any([first, second, third]);

    //First one to be successfull will be the value of firstResponse
    console.log(firstResponse);
  } catch (error) {
    console.log(error);
  }
};

promiseAny();
```

In this example, we have all the promises resolving, and the first one to respond is the one that will be assigned to _firstResponse_. But what if one of them rejects
or maybe two of them reject? Then we will get the one that resolved:

```js
// We use delay to simulate response from an API
const delay = () => Math.floor(Math.random() * 1000);

const first = new Promise((resolve, reject) => {
  setTimeout(() => reject('First'), delay());
});

const second = new Promise((resolve, reject) => {
  setTimeout(() => reject('Second'), delay());
});

const third = new Promise((resolve, reject) => {
  setTimeout(() => resolve('Third'), delay());
});

const promiseAny = async () => {
  try {
    const firstResponse = await Promise.any([first, second, third]);

    //Third one will be the value of firstResponse
    console.log(firstResponse);
  } catch (error) {
    console.log(error);
  }
};

promiseAny();
```

Here we have _first_ and _second_ promise being rejected. The _third_ is getting resolved, that's why we will always get _third_ as our response from Promise.
And if all of them were rejected, we would get an error that says **AggregateError: All promises were rejected**. Here is a code example of that:

```js
// We use delay to simulate response from an API
const delay = () => Math.floor(Math.random() * 1000);

const first = new Promise((resolve, reject) => {
  setTimeout(() => reject('First'), delay());
});

const second = new Promise((resolve, reject) => {
  setTimeout(() => reject('Second'), delay());
});

const third = new Promise((resolve, reject) => {
  setTimeout(() => reject('Third'), delay());
});

const promiseAny = async () => {
  try {
    const firstResponse = await Promise.any([first, second, third]);

    //This will not be executed since our Promise throws error
    console.log(firstResponse);
  } catch (error) {
    // Here we will get our error: AggregateError: All promises were rejected
    console.log(error);
  }
};

promiseAny();
```

Now let's see how **Promise.any()** compares to other Promise methods:

```js
// Here we wait for all promises to finish but if one fails, we throw an error
Promise.all([first, second, third]);

// Here we wait for first promise to finish, failed or sucessfull
Promise.race([first, second, third]);

// Here we wait for all promises to finish, and array of all promises is returned
// with their status and values or reason if it's rejected
Promise.allSettled([first, second, third]);

//Here we wait for the first that is succefull or all of them failed
Promise.all([first, second, third]);
```

And here is where you can read more about this feature [Promise.any()](https://github.com/tc39/proposal-promise-any)

## Logical Assignment Operators

This feature was inspired by the Ruby programming language, and we use it to write conditional checks in shorter forms. There is not a lot to explain here since we
already had these, but this is just a shorter version. Here is an example of usage:

```js
// x = x || 0
// x ||= 0
// x = x ?? 0
// x ??= 0
// x = x && 0
// x &&= 0

const multiply = (dot) => {
  dot.x ??= 2;
  dot.y ??= 2;
  return dot;
};
multiply({ x: 0 }); // 4
```

So for **dot.x ??= 2** , if **dot.x** is not `null` or `undefiend` we will leave it's value assigned to him, but if it's `null` or `undefiend` we will assign 2. This sign ??
is called **Nullish Coalescing operator** and it specifically checks if the value is `null` or `undefined. It was added in ES2020 to the Javascript.

If you want to see more about this feature go to the official GitHub repo [Logical Assignment Operators](https://github.com/tc39/proposal-logical-assignment).

## Numeric separators

This feature was added to improve the readability of numbers. So if you write a large number it's hard to see, so you can use this to separate hundreds, thousands, etc.
Here is an example usage of this:

```js
const largeNumer = 12000000000;

const largeNumberFormated = 12_000_000_000;
```

You can see that it helps read if this is millions, billions, or trillions. Go to the GitHub repo to read more about it [Numeric separators](https://github.com/tc39/proposal-numeric-separator)

## WeakRefs

Before I say anything about this feature, I have to say that possibility of us needing to use this is quite small. This is a bit higher level Javascript, but I'll try to
explain anyway, who knows maybe we'll use it one day 🤣.

In Javascript, we have Garbage Collectors(GC), which means that the Javascript engine cleans unused values so it can free memory and set something else in that place.
So if we have a variable **let person** that is referencing an object that means that we have a strong reference to that object, and as long something has a reference
to that object, that object will not get Garbage Collected which means it will not get removed from memory.

So if we have an object in memory that no one is referencing, there is a possibility that it will get GC. And why I say maybe is because GC is non-obvious in Javascript which means that it is not certain when GC will happen
and if it will happen at all. And also GC work differently on different Javascript engines, so Google Chrome V8 will have a different GC from Firefox that is using
Spider monkey engine.

> NOTE: In Javascript, only Objects and Strings are Garbage Collected

**WeakRefs** are weak references to the objects in memory, and that means that we are not strongly pointing to that object and if GC happens
we will not point to anything anymore, and the variable that we assigned **WeakRef** to will be undefined. We can check if **WeakRef** has value by calling **deref()**
and if we get _undefiend_ that means that object was removed by GC, and if we get a value means an object is still in memory and we can use it. Here is an example of how we
can do that:

```js
const value = {
  name: 'Vehid Trtak',
  city: 'Sarajevo'
};

//Create weak reference to the value
const weakRef = new WeakRef(value);

//Check if values still exists
const maybeValue = weakRef.deref();
if (maybeValue === undefiend) {
  // Value was removed by GC
} else {
  // Value is still available
}
```

There is also one more thing that can be used with **WeakRefs** and its FinalizationRegistry. This is a way for us to get notified when our value is Garbage Collected,
so we don't have to check **deref()** all the time to see if it still exists. And here is code showing how to use it:

```js
const notify = new FinalizationRegistry((value) => {
  // Do something when you get notified
});
```

> NOTE: When **FinalizationRegistry** callback is executed that means that values are already removed and the object doesn't exist in memory anymore!

Since this is a complex topic, and even people that propose this to be added to Javascript are telling that you probably shouldn't use this unless you know what you are doing
I won't spend any more time, if you want to check more check here [WeakRefs and FinalizationRegistry](https://github.com/tc39/proposal-weakrefs).

## Conclusion

We got through these five new additions, some of them useful and some of them not so much. Hope you found this useful, and if you did share the knowledge so others can
learn about it too. And check the official GitHub repository and see what else is there, maybe there is good stuff from previous Javascript updates, or maybe to check
things that are planned for future releases like [Records and Tuples](https://github.com/tc39/proposal-record-tuple).


New ES2021 Javascript features


_How do immutability works in Javascript, and how to handle it correctly_

> **NOTE:** I want to add that you should try these examples yourself and research more for
> an even better understanding

One of the important topics for Javascript is the behavior of an object since Javascript itself is object-based and objects are used a lot. Understanding how objects work will benefit you while working with Javascript. You will understand the code better and you will be able to avoid many bugs. So in this post, I'll explain how objects actually work in Javascript and how to use them correctly.

> There are few ways for you to create an immutable object, but we will cover the two most used ones:
>
> **ES6 Spread operator** and
> **ImmerJS library**

If you create an object like it is shown in the example below, this will create an object in memory and a variable name will reference/point to that object. And like any other variable, you can use, change and do whatever with it.

```js Example.js
const name = {
  first: 'Vehid',
  last: 'Trtak'
};
```

But the tricky thing comes up if you want to create a new object with the same values. Consider the following example:

```js Example.js
const name = {
  first: 'Vehid',
  last: 'Trtak'
};
const secondName = name;
secondName.first = 'Vedad';
```

What do you think **`console.log(name)`** will print?
If you said **"Vehid"** you are wrong. The reason is that when we created our _secondName_ variable we have assigned the reference of the object and not the object itself to the variable.
This means that they reference the same object, and if you change the value of one object it will affect the other as well. For example:

<div className='gif-container'>
  <img src='/js-imute.webp' />
  <p className='gif-credentials'>
    Animation by{' '}
    <a
      target='_blank'
      rel='noopener noreferrer'
      href='http://www.linkedin.com/in/fatima-abdel-monem-trtak-09a39012a'
    >
      Fatima Trtak
    </a>
  </p>
</div>

```js Example.js
const name = {
  first: 'Vehid',
  last: 'Trtak'
};

const secondName = name;
secondName.first = 'Vedad';

console.log(name);
/* const name
{
first: "Vedad",
last: "Trtak"
}
*/
console.log(secondName);
/* const secondName
{
first: "Vedad",
last: "Trtak"
}
*/
```

And as you can see here, after we changed our _secondName_ object it affected our _name_, because they have the same reference in memory.

> You can also copy the example and try it to see what it prints in the console, and maybe change few things to get a feeling of what happens when you change variable values.

Probably your questions now are: _Ok now what? I understand that we have references and if multiple variables point to the same object,_
_changing one will affect all of them. What to do to prevent that, how can I create the same object and modify it without affecting other objects._
Well, there are few ways to do this. The first, probably most used method, is called spread operator.

```js spread-object.js
const name = {
  first: 'Vehid',
  last: 'Trtak'
};

const secondName = { ...name };

secondName.first = 'Vedad';

console.log(name);
/* const name
{
  first: "Vehid",
  last: "Trtak"
}
*/
console.log(secondName);
/* const secondName
{
  first: "Vedad",
  last: "Trtak"
}
*/
```

<div className='gif-container'>
  <img src='/js-imute-shallow.webp' />
  <p className='gif-credentials'>
    Animation by{' '}
    <a
      target='_blank'
      rel='noopener noreferrer'
      href='http://www.linkedin.com/in/fatima-abdel-monem-trtak-09a39012a'
    >
      Fatima Trtak
    </a>
  </p>
</div>

As you can see, it's quite easy, just use three dots before the value name and new object reference will be created with the same values as _name_.
This is important for a library like ReactJS which depends on objects changing references and not only values,
since changing, reference will cause re-render, and changing value without reference will not.
You can read more about this topic in the post about [ReactJS Immutability and Mutability](http://vehidtrtak.com/blog/reactjs-immutability-mubtability).

> **NOTE:** Using spread operator will only create **shallow copy** of the object, which means that it will only copy
> first level of object and the children will still be referencing the old object ℹ

Example of shallow copying object:

```js shallow-copy.js
const name = {
  first: 'Vehid',
  last: 'Trtak',
  address: {
    street: 'First avenu',
    number: '123A'
  }
};

const secondName = {
  ...name
};
secondName.first = 'Vedad';
secondName.address.street = 'Second avenu';

console.log(name);
/* const name
{
  address: {
    number: "123A",
    street: "Second avenu"
  },
  first: "Vehid",
  last: "Trtak"
}
*/
console.log(secondName);
/* const secondName
{
  address: {
    number: "123A",
    street: "Second avenu"
  },
  first: "Vedad",
  last: "Trtak"
}
*/
```

You can see here changing the nested object address will affect the address of the other object as they have the same reference.
It happened to me few times at the start of my career and caused me some bugs, so I'm mentioning it here so it can help others to be aware of this behavior and prevent potential bugs 😊

Now next step is to figure out how to copy the whole object with all the children and create separate references?

One of the ways is using spread operator for children:

```js deep-copy.js
const name = {
  first: 'Vehid',
  last: 'Trtak',
  address: {
    street: 'First avenu',
    number: '123A'
  }
};

const secondName = {
  ...name,
  address: { ...name.address }
};
secondName.first = 'Vedad';
secondName.address.street = 'Second avenu';

console.log(name);
/* const name
{
  address: {
    number: "123A",
    street: "First avenu"
  },
  first: "Vehid",
  last: "Trtak"
}
*/
console.log(secondName);
/* const secondName
{
  address: {
    number: "123A",
    street: "Second avenu"
  },
  first: "Vedad",
  last: "Trtak"
}
*/
```

<div className='gif-container'>
  <img src='/js-imute-deep.webp' />
  <p className='gif-credentials'>
    Animation by{' '}
    <a
      target='_blank'
      rel='noopener noreferrer'
      href='http://www.linkedin.com/in/fatima-abdel-monem-trtak-09a39012a'
    >
      Fatima Trtak
    </a>
  </p>
</div>

Now we have deeply copied objects, we can work with them without having them affecting each other.
But as you may see, this way things can become very complicated, ugly and not easy to understand what is going on.

To show you what exactly I mean by this, here is an example of an object with deeply nested values:

```js
const name = {
  first: 'Vehid',
  last: 'Trtak',
  address: {
    home: {
      street: 'First avenu',
      number: '123A'
    },
    work: {
      street: 'Second avenu',
      number: '123A'
    }
  }
};

const secondName = {
  ...name,
  address: {
    ...name.address,
    home: {
      ...name.address.home
    },
    work: {
      ...name.address.work
    }
  }
};
secondName.first = 'Vedad';
secondName.address.work.street = 'Third avenu';

console.log(name);
/* const name
{
    "first": "Vehid",
    "last": "Trtak",
    "address": {
        "home": {
            "street": "First avenu",
            "number": "123A"
        },
        "work": {
            "street": "Second avenu",
            "number": "123A"
        }
    }
}
*/
console.log(secondName);
/* const secondName
{
    "first": "Vedad",
    "last": "Trtak",
    "address": {
        "home": {
            "street": "First avenu",
            "number": "123A"
        },
        "work": {
            "street": "Third avenu",
            "number": "123A"
        }
    }
}
*/
```

This approach gets ugly very quickly. Having to copy all children will be too much repetition and will be more prone to errors. So what I usually do is use a spread operator for objects that are not too deep, and not with too many properties. If, on the other hand, I have deeply nested properties and/or many properties, or maybe working
with Redux, I prefer to use a library like [Immer](https://immerjs.github.io/immer/).
What is nice about Immer, especially when working with Redux, is that it enables you to use mutable ways of working with objects, then in the background, it will convert them to immutable values.

Here is an example with ImmerJS, showing how much easier it can be:

```js immer.js
import produce from 'immer';

const name = {
  first: 'Vehid',
  last: 'Trtak',
  address: {
    home: {
      street: 'First avenu',
      number: '123A'
    },
    work: {
      street: 'Second avenu',
      number: '21st'
    }
  }
};

const secondName = produce(name, (newName) => {
  newName.first = 'Michael';
  newName.last = 'Johnes';
  newName.address.home.street = 'New street';
  newName.address.work.street = 'Old avenu';
});

console.log(name);
/* const name
{
    "first": "Vehid",
    "last": "Trtak",
    "address": {
        "home": {
            "street": "First avenu",
            "number": "123A"
        },
        "work": {
            "street": "Second avenu",
            "number": "21st"
        }
    }
}
*/
console.log(secondName);
/* const secondName
{
    "first": "Michael",
    "last": "Johnes",
    "address": {
        "home": {
            "street": "New street",
            "number": "123A"
        },
        "work": {
            "street": "Old avenu",
            "number": "21st"
        }
    }
}
*/
```

Also, I want to mention that many libraries can be used, like Immer or Immutable. But this post was about objects in Javascript, their behavior, how to handle them, and immutably change their values.

## Conclusion

We got through what immutability and mutability in javascript are, how it works, and how to work with it.
Also, we explained how objects work, how to use them, and what to watch for when working with objects.

Congratulation on getting through this post! It's valuable knowledge that you gained here. The next step could be for you to test this knowledge to get an even better understanding. Try different scenarios, and see what happens. And if you are React developer, definitely check [ReactJS Immutability and Mutability](http://vehidtrtak.com/blog/reactjs-immutability-mubtability)
