![Experiment, Nicolas Thomas, unsplash](nicolas-thomas-3GZi6OpSDcY-unsplash.jpg)

A while ago, I was reading an RFC from react's RFCs called [`useMutableSource`](https://github.com/reactjs/rfcs/blob/master/text/0147-use-mutable-source.md); it was an experimental feature that, in a nutshell, lets you safely read, write and even edit an external source (outside of the react components tree). It's a banger feature, which I'm really chuffed for it, but it's experimental at the same time. You may know that I'm working on an Open-source state-management library called jotai. This library announced a new feature, the Provider-less mode. To know what it is, think of React Context, but no need for a `Provider` component, it's not exactly that, but it gives you the idea.

## Why a new one?

Yea, we have patterns and libraries that allow us to read and write from an external source, but as I said, this one lets you do things safely; no tearing anymore.

## Tearing

Think of tearing as something like if we have a value(state) that A and B read from it, but somehow in the rendering, the value changes. The B component is later than A, So in Rendering, the value in the A component is 0, and in the newer component (B), the value is 1. We call this tearing; it means you see two different values in the viewport from one exact source. It's a new and hard to understand implementation in React concurrent mode; for more information, see [this](https://stackoverflow.com/questions/54891675/what-is-tearing-in-the-context-of-the-react-redux). 

## Experimental, Why should I use it?

So I thought about this, we have two options:

- Experimental version of react: `yarn add react@experimental`
- Consistent version of `useMutableSource`, you can copy paste it from [here](https://gist.github.com/Aslemammad/0e0a4eff774f991df47fa7c6cd219174)

I recommend the second option because it's not going to change, and good for now as long as we don't have `useMutableSource` in a major react version.

## Context with no Provider

I think we have reached what brought you here, but wait before all of this, don't forget to look at my [Github](https://github.com/Aslemammad) and [Twitter](https://twitter.com/aslemammadam); you're going to see cool stuff there and help me with my learning journey too. So let's start.

> Some of the code below is written with typescript, so it will be more understandable, even for people who don't know typescript.

### Start

First we need to create a simple global object, which contains three properties:

```tsx
 const globalStore = {
  state: { count: 0 },
  version: 0,
  listeners: new Set<() => any>()
};
```

- `state`: simple value like react Context value
- `version`: important part that has to change whenever any part of the state changes
- `listeners`: a set of functions that we call them every time we change part of the `state`, so we notify them about the changes

Now we need to create a mutable source from `globalStore` and give it the version, so it'll help it with triggering new changes, so we're going to access it in `getSnapshot` and `subscribe`; we'll talk about these soon.

```tsx
const globalStoreSource = createMutableSource(
  globalStore,
  () => globalStore.version // (store) => store.version (Optional) if you use the consistent and non-experimental version of useMutableSource
);
```

Now it's the time to talk about `getSnapshot`; in a nutshell, it's a function that `useMutableSource` returns its returned value whenever the state changes.

```tsx
const cache = new Map();

const getSnapshot = (store: typeof globalStore) => {
  const setState = (
    cb: (prevState: typeof store.state) => typeof store.state
  ) => {
    store.state = cb({ ...store.state });
    store.version++;
    store.listeners.forEach((listener) => listener());
  };
  if (!cache.has(store.state) || !cache.has(store)) {
    cache.clear(); // remove all the old references
    cache.set(store.state, [{ ...store.state }, setState]); // we cache the result to prevent useless re-renders
    // the key (store.state) is more consistent than the { ...store.state },
    // because this changes everytime as a new object, and it always going to create a new cache
    cache.set(store, store); // check the above if statement, if the store changed completely (reference change), we'll make a new result and new state
  }

  return cache.get(store.state) as [typeof store.state, typeof setState]; // [state, setState]
};
// later: const [state, setState] = useMutableSource(...)
```

Take a look at the `setState` function, first we use `cb` and pass it the previous state, then assign its returned value to our state, then we update the store version and notify all the listeners of the new change.

> we used the spread operator `({ ...store.state })` because we have to clone the value, so we make a new reference for the new state object and disable direct mutations.

We don't have any `listener` yet, so how we can add one? with the `subscribe` function, take a look at this:

```tsx
const subscribe = (store: typeof globalStore, callback: () => any) => {
  store.listeners.add(callback);
  return () => store.listeners.delete(callback);
};
```

This function's going to get called by `useMutableSource`, So it passes `subscribe` two parameters:

- `store`: which is our original store
- `callback`: this is going to cause our component a re-render (by `useMutableSource`)

So when `useMutableSource` calls the subscribe, we're going to add the `callback` to our listeners. Whenever something changes in the state (`setState`), we call all of our listeners so that the component will get re-rendered. That's how we have the updated value every time with `useMutableSource`.

So you may wonder we delete the callback in return, the answer is that when the component unmounts, `useMutableSource` will call `subscribe()`, or in another term, we call it `unsubscribe`. When it gets deleted, we'll no longer call a useless callback that will cause a re-render to an unmounted (or sometimes an old) component.

### `useContext`

Now we reached the end line, don't think too much about the name, we just wanted to mimic the Provider-less version of React context. 

```tsx
export function useContext() {
  return useMutableSource(globalStoreSource, getSnapshot, subscribe);
} // returns [state, setState]
```

Now we can use this function everywhere we want. Take a look at this example, or if you want, you could go straight for the [codesandbox](https://codesandbox.io/s/usemutablesource-react-context-spyhu?file=/src/App.tsx). 

```tsx
function Display1() {
  const [state] = useContext();
  return <div>Display1 component count: {state.count}</div>;
}
function Display2() {
  const [state] = useContext();
  return <div>Display2 component count: {state.count}</div>;
}
function Changer() {
  const [, setState] = useContext();
  return (
    <button
      onClick={() =>
        setState((prevState) => ({ ...prevState, count: ++prevState.count }))
      }
    >
      +1
    </button>
  );
}
function App() {
  return (
    <div className="App">
      <Display1 />
      <Display2 />
      <Changer />
    </div>
  );
}
```

Now whenever you click the +1 button, you can see the beautiful changes without any `Provider`.

I hope you enjoyed this article, and don't forget to share and reaction to my article. If you wanted to tell me something, tell me on [Twitter](https://twitter.com/aslemammadam) or mention me anywhere else, You can even subscribe to my [newsletter](https://bugged.dev/newsletter).

A while ago, I was reading an RFC from react's RFCs called useMutableSource; it was an experimental feature that, in a nutshell, lets you safely read, write and even edit an external source.

React Context without Provider + useMutableSource

![Fuji-Q Highland, Priscilla Du Preez, unsplash](priscilla-du-preez-FOsina4f7qM-unsplash.jpg)

I'm not 16 anymore from now on (Feb 15, HBD to myself🎉), But my 16th (2020-21) year on earth was the first year of my professional career where I started learning and making things seriously, so be with me and see the highlights. Hope you like this wild journey.
## 2020
The most miserable year in the 21st century, everyone knows about it, we lost many friends, many jobs and many things I'm so sorry about. Still, at the same time, it was a productive year for me, no hanging out, less school and it empowered my programmers-life lifestyle. I think every programmer feels the same, doesn't?
So let me start the main thing and tell you about my career.
## The beginning
Actually I didn't expect such a year specifically for me. I had many ups and downs, but they made my year so exciting. I didn't know that I would be an active Github user or be in a job position (Thank you, [Hossein](https://github.com/HosseinShabani), for helping me in that); it was all unexpected. I expected a typical year like any standard years I've passed, but it was really different. 
## Svelte vs React
I was learning HTML/CSS and javascript and practising them more and more, but everyone kept telling me that I have to choose a framework/library. Most beginners had the Vue vs React or React vs Angular dilemma, but I had a different one you saw in the heading. I was exploring [dev.to](http://dev.to); everyone's talking about svelte future, Learning it, and why we should. However, we had many react developers, and react itself grows day by day, I didn't know which to choose. I randomly chose svelte and learned many great things about it. Actually, even I don't know what to suggest to beginners; I may tell svelte to newbies first because, don't want to exaggerate but if you deep dive into react hole, you won't get out of it quickly. 
## So Svelte

Nice looking technology, no challenging concepts and no state-management options anymore, It's literally all-in-one. I really loved its docs, and you can take a look [here](https://svelte.dev/tutorial/basics), learn things so fast with the live examples in front of you. Absolutely I had some difficulties in learning svelte, but when I take a look at them now, they weren't that hard.

I really loved the way svelte treats global stores, syntax and reactivity, so genius. I think svelte is so potent that it needs a more significant community to take over most modern technologies. 

[My friend](https://github.com/blackestwhite)'s team and I planned to make an idea into a real-world project, so the front-end was with me, I built it with svelte, the experience was incredible, but unfortunately, we cancelled the project. Here's the project [repository](https://github.com/ArimaTeam/LyricBox) (Don't bother me for my dumb commit messages).
## React
I joined many communities, and everyone was a reactjs developer, I couldn't even talk about React; So I had to join reactjs. When I joined react community, I found out why they don't talk about things except react. I just said that's it, that is what I want. 

I started practising and doing stuff, shared some of them in Github and some not. Started reading articles about reactjs from different authors. Then I made my first ever npm package called contextism, and I was inspired by one of [kent](https://github.com/kentcdodds)'s posts about reactjs context API, Seeing others use your stuff is one of the best feelings ever. That's how I fell in love with creating and helping others. 
## Open-source
But wait, Contextism wasn't my first open-source activity. It was [Espresso](https://github.com/disizali/espresso), So what is Espresso? It's something like expressjs but not for nodejs; it's for denojs, we made it when all developers talked about a new trend called deno. Thanks for [Ali Hasani](https://github.com/disizali) for bringing me into contributing javascript libraries.
![Hacktoberfest T-shirt](hacktoberfest-T-shirt.png)
## [Hacktoberfest](https://hacktoberfest.digitalocean.com/)
If you don't know about this monthlong celebration, let me tell you that it's one of the best things for open source (as long as spammers don't attend). I contributed to these repositories in this celebration:
### [Carbon](https://github.com/carbon-app/carbon)
It has an ugly source code but a challenging one, I refactored some code and sent a pull request to the repository, it was a special feeling for me.
### [Jotai](https://github.com/pmndrs/jotai)
How should I start with this? It started with just 3 pull requests for Immerjs combination, and now I'm a collaborator there. I really love this package. If you know Recoil, forget about it, we have a better one, it's jotai. I learned about promise batching, acceptable pull requests and even how to manage a repository. Thanks, [Daishi](https://github.com/dai-shi).
## Writing
The best way of learning is teaching, that's weird, but that's how it is. I started writing stuff because [swyx](https://github.com/sw-yx)'s Learn-In-Public inspired me, then I decided to make my own blog with my own domain, That's why I started [Bugged.dev](https://bugged.dev). I'm in love with writing, suggest you start too, it's not that hard, but it takes time to dive into the writing routine. It's so fun to share your drafts with your friends and let them review your drafts; I always share them with my friends like [Ali](https://github.com/aliPMPAINT).
## [Poimandres](https://github.com/pmndrs)
Contributing to jotai, valtio and eslint-plugin-valtio made and some other libs made me into such a lovely, friendly and active group. We maintain many wondrous things; you can take a look at our Github. Thanks, [Paul](https://github.com/drcmda), for letting me in.

In the end, I'm fortunate for having my family, A supportive and helpful one, and I really wanted to thank them for everything. I have many plans for my 17th. I'll write about them slowly. Lucky too for having such readers hope you liked this post, don't forget to show me your reactions also, really love you all. Alhamdulillah.

I'm not 16 anymore from now on (Feb 15, HBD to myself🎉), But my 16th (2020-21) year on earth was the first year of my professional career where I started learning and making things seriously...

A wild ride in my 16th year

![Chicago Skydeck, Tim Trad, unsplash](tim-trad-AIwlyvpQJ18-unsplash.jpg)

All of us, for one time at least, have plotted to contribute to one open-source library, it goes well but when we take a look at the source code, we become incapable and dumb, we can't even get our head around it.

Today I want to show you my approach to read libraries and understand them thoroughly, I don't think it's the best approach, but let's give it a shot, it worked so well for me.

> If you don't know what library you must start with, I suggest you check [this](https://kentcdodds.com/blog/what-open-source-project-should-i-contribute-to) article by Kent C Dodds.

## Needs

- VS code( or any code editor that you can attach a debugger to it)
- Debugger
- VS code jest extension( we can work without) or node debugger🤷🏻‍♂️
- Your favourite project( I use [jotai](https://github.com/pmndrs/jotai) this time)

> Sometimes we need to set our own node version on 14 because I saw the debugger has some struggles with the 15 version.

Make sure you have some background of the library docs, then open the library's source code, so let's start our journey and drink the coffee( I don't do actually) because I'm really passionate to get it out of my system. 

## Start

Most of the times I won't open the `index.js` file, because many branches of the library tree are there, and we don't have clue about any of that yet. I suggest that you check the tests first, so you can debug the tests and see how the library works. 

## Settings

Jotai has jest tests, so I can debug its tests with [jest](https://marketplace.visualstudio.com/items?itemName=Orta.vscode-jest) extension. I just need to create a config file there.

```json
// .vscode/launch.json
{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "name": "vscode-jest-tests",
      "request": "launch",
      "program": "${workspaceFolder}/node_modules/jest/bin/jest",
      "args": ["--runInBand", "${file}"],
      "cwd": "${workspaceFolder}",
      "console": "integratedTerminal",
      "internalConsoleOptions": "neverOpen",
      "disableOptimisticBPs": true
    }
  ]
}
```

I use this config most of the times, but it depends on your project sometimes, for example in the Reactjs source code, you have to link the `jest-cli.js` as a program instead of the jest itself.

## Breakpoints

For example, I'd love to see how `useAtom` works, so I just need to go to the related test and set a breakpoint on the line that I want to know more about. Then, we can run the `vscode-jest-tests`

config, so it's gonna run the file we were in, and it would be stopped on the line we set a breakpoint⏹️ on.

![vscode-jest-debugger](vscode-jest-debug.png)

Now we have to play with the debugger bar( right corner) and watch the code execution flow, we can just set many breakpoints wherever we want and understand what's happening there.

I hope this article encourages you to do more open source and kills your fears( not all of them actually). It's time to party again, so don't forget to share this little article, It's my first 2021 article after 3 bloody months, I'm trying to post more, so help me to do so with your reactions.

All of us, for one time at least, have plotted to contribute to one open-source library, it goes well but when we take a look at the source code, we become incapable and dumb...

How to read open-source js libraries

![Marc Sendra Martorell, unsplash](marc-sendra-martorell--Vqn2WrfxTQ-unsplash-min.jpg)
  

Sometimes we have complete APIs, but maybe at the same time, they're not, but I am happy with that. We can’t expect everything we need to be in one specific tool.
  

In React or Next, the same thing applies. They can’t implement all of the hooks we need, but they can permit us to, and they do. The permit that I'm talking about is something like [IOC](https://kentcdodds.com/blog/inversion-of-control).

  

## The problem 🤔

The problem was I wanted the same state in my component to be in the query, that's possible and easy to think, but not that easy to write in every component.

  

Let's bring some solutions that I don't like.

```jsx
const [count, setCount] = useState(0);

const { pathname, push, asPath } = useRouter();

const [query, setQuery] = useState({});

useEffect(() => {
  push(pathname, { query: { count: count } }, { shallow: true });
}, [count]);

useEffect(() => {
    setQuery(parseUrl(asPath).query);
}, [asPath]);
```

I've no problem with this code but imagine when we have a ton of components that we need to manage the query in them, it would be awful.

We'll use the **router** hook in every component, two **useEffect**s (we can put them in one), we need to parse the path and push the changes to the query, It's hard for me to do such a thing.

## The solution 😍

I think sometimes we can write a little bit more code that could make our lives easier, that's what we're going to do. We'll use more functions and hooks for our new hooks.
I wanted to implement a simple pattern like **[useQuery](https://react-query.tanstack.com/docs/guides/queries)** or **useEffect**, see this:
```jsx 
const {
  queries,
  addQueries,
  deleteQuery,
  clearQueries
} = useNextQuery(() => ({}));
```
In the first hook we make, we can see the queries state, add new queries, and delete one. WOOOOW.
```jsx
useNextQueryEffect(() => {
  return { count: count };
}, [count]);
```
And the second hook is based on the first one, and it's similar to **useEffect**, it takes some dependencies and when they change, it sets the returned object as the new query object. if the last argument is true, it will clear the previous query.

## Let's build
First we need to access the routing system in Next.js, so we shall use **useRouter** hook. 
```jsx 
const useNextQuery = (initialQuery = {}, shallow = true) => {
  const { asPath, push, pathname } = useRouter();
};
```
If you don't know about **asPath**, **push**, and **pathname**, Here's Next.js docs explanation:
* **asPath**: Actual path (including the query) shown in the browser.
* **pathname**: Current route. That is the path of the page in */pages*
* **push**: Handles client-side transitions, this method is useful for cases where *next/link* is not enough.

In this hook, we take the first argument from the user as an Initial State( or Initial Query), and the second one is for shallow transition, I'll talk about it.
### Initial state
When the component mounts, we need to access the queries in the url and return them as the first queries.
```jsx
const [state, setState] = useState(() => {
  const { query: initialRouteQuery } = queryString.parseUrl(asPath);
  return { ...initialQuery, ...initialRouteQuery };
})
```
In useState we pass a callback, It's called [lazy initialization](https://kentcdodds.com/blog/use-state-lazy-initialization-and-function-updates), and it's a perfect thing for performance.
[Query-string](https://www.npmjs.com/package/query-string) package is so useful, we use it to parse the **asPath** string, But if you don't like to use foreign libraries, you can implement your algorithm. If we pass our initial query to the hook, it will be mixed with the url-based initial query, then we set the query in the url. So:

* Take the initial query parameter as **initialQuery**
* convert the **asPath** to an object called **initialRouteQuery**
* Mix them and set them or push them( in the next steps)

### Push
The query shall be up-to-date and when the state changes the query must change too. We can use **useEffect** to watch the state changes. 
```jsx 
useEffect(() => {
  push(
    pathname,
    {
      query: state
    },
    { shallow: shallow }
  );
}, [state]);
```
So whenever the query state changes, we push the changes to the route. We don't want the route changes, so we keep the same pathname. 
The [shallow](https://nextjs.org/docs/routing/shallow-routing) option gives us the ability to manage server-side rerunning and we take it from the second parameter in **useNextQuery**.

### Up-to-date
The state needs to be up-to-date with the query too, and this can be done with listening to **asPath**( I'm not sure about this solution's performance, if you have better one, [comment](https://github.com/Aslemammad/Bugged.dev/issues/new) me😅).
```jsx 
useEffect(() => {
  const { query } = queryString.parseUrl(asPath);
  setState({ ...state, ...query });
}, [asPath]);
```
Here when the state changes, the upper useEffect will run again and keep the state and the query up-to-date.

### Methods
It's a simple step, we just create three functions that modify the state and then the query will change.
```jsx
const addQueries = (newQueries) =>
  setState((prevState) => ({ ...prevState, ...newQueries }));

const deleteQuery = (oldQuery) =>
  setState((prevState) => {
    const { [oldQuery]: deletedQuery, ...rest } = prevState;
    return rest;
  });

const clearQueries = () => setState({});

return {
  queries: state,
  addQueries,
  deleteQuery,
  clearQueries
};
```
Haha, we finished the first hook, there is another small one and then 💣💥.

## useNextQueryEffect
I really like this one, everytime I look at it, i feel how much my life is easier now( little exaggeration😅). We give it the dependencies and whenever they change, this hook will push the query based on the returned value from our callback. 
### Parameters
This hook needs one **callback** for running after every state changing, **dependencies** to watch, and **clear** option if we needed to clear the unnecessary queries.
### Let's start  
```jsx
const useNextQueryEffect = (cb, deps, clear) => {
  const { queries, addQueries, clearQueries } = useNextQuery({}, true);
  ...
};
```
Absolutely we won't rewrite everything, we'll use our previous hook and its methods to manage the query.

The first goal we wanted to achieve by this hook is listening to the dependencies, so we're going to use **useEffect** again.
```jsx
useEffect(() => {
  ...
}, deps);
```
The callback should be in the **useEffect** because we need to call its returned value every time the state changes, I said the returned value and not the callback itself, so we're gonna pass its returned value to the **addQueries**.
So: 
```jsx 
useEffect(() => {
  addQueries(cb());
}, deps);
```
 Now I think we have a good hook, but I feel there is something that I missed, Yesss, like **setState**'s previous state, I need the previous query. 

 For the third parameter( clear option), I just need the clearQueries method from our previous hook. 
 ```jsx
useEffect(() => {
  const prevQueries = queries;
  if (clear) {
    clearQueries();
  }
  addQueries(cb(prevQueries));
 }, deps);
``` 
I put the **previousQueries** before the clear condition, as you know we can't put it after, because sometimes the clear option will clear the queries and the **prevQueries** will be an empty object.
And Yesss, that's it.
## Conclusion
I always struggled with such problems, and I made a [package](https://github.com/Aslemammad/contextism) from one of them once, So If you wanted to make a npm package from this idea, no problem, I'll be the first one  to use it.

So let's party, Hooora🎉🥳, we've made our lives easier now. I've gotten a good example for you, feel free to fork it. If you wanted to see how the query works with the url, press the *open Sandbox*.

<iframe src="https://codesandbox.io/embed/query-article-7h20b?fontsize=14&hidenavigation=1&theme=dark"
     style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;"
     title="query-article"
     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"
   ></iframe>

I hope you enjoyed this small article and You know we don't have likes or comments here, but you can share it. If you wanted to tell me something, tell me on Twitter or mention me anywhere else, You can create an [issue](https://github.com/Aslemammad/Bugged.dev/issues/new) in GitHub too. 

Sometimes we have complete APIs, but maybe at the same time, they're not, but I am happy with that. We can’t expect everything we need to be in one specific tool.

Let's build 2 hooks to manage Next.js Queries


![Trees, Berat Çıldır, unsplash](tree-shaking.jpeg)

> Tree shaking is a term commonly used in the JavaScript context for dead-code elimination. It relies on the static structure of ES2015 module syntax, i.e. import and export. The name and concept have been popularized by the ES2015 module bundler rollup. [Webpack](https://webpack.js.org/guides/tree-shaking/)

We're not going to deep dive in **tree shaking**, just talk about its benefits and examples. If you're an npm package developer, You should check out [Webpack tree shaking](https://webpack.js.org/guides/tree-shaking/) or [Rollup tree shaking](https://rollupjs.org/guide/en/#tree-shaking) to give the users and developers a better experience.

Tree shaking is a simple concept to reduce the size of production build to have faster TTFB (Time To First Byte or page load time).

## Why? 🤔
It allows the bundler to modify some parts of the production code to remove the unused parts. 

Imagine we have a file **meet.js**: 
```js
// meet.js
function hi() {
    ...
}
function bye() {
    ...
}

export { bye, hi }
```
Now import it in another file: 
```js
import { hi } from './meet.js'

hi();
```
Here is the point, maybe you thought we just imported the **hi**, but not, We imported all of the **meet.js**, that means we have **bye** in the production, too. So the production build has unused code, so we don't want that.

In some packages, we do this too, we import the needed parts, but in production, we have unused code when using object destructuring, but there is a way to get rid of the unused code! 

## How? 😬

Here we can use tree shaking, but if the package that we're using implemented the tree shaking feature.
```js
import { chunk } from 'lodash-es/array/chunk'
```
Almost every package has its way to implement its tree shaking, and it's not wildly different!

For bigger packages, see What happens when we don't use tree shaking. 
```js 
import { chunk } from 'lodash-es' // No tree shaking
// 30Kb just for one function, what! 👎

import { chunk } from 'lodash-es/array/chunk' // With tree shaking
// 1Kb for one function, That's awesome 👍

// https://github.com/webpack/webpack/issues/1750
```

## Note
I think you should use or implement this feature because reducing the build size is so important and the users love the speed. In the previous [article](/post/Next-Dynamic-imports), I said to use the dynamic import feature when you have TTFB issues, and if you use it always, It will affect the TTFB and slows it down sometimes, But tree shaking is a great feature, So use it always when you can.

I hope you enjoyed this small article and You know we don't have likes or comments here, but you can share it. If you wanted to tell me something, tell me in twitter or mention me anywhere else, You can create an issue in GitHub too. 🐞

Tree shaking is a simple concept to reduce the size of production build to have faster TTFB (Time To First Byte or page load time)...

Tree shaking goodness


> **Dynamic import()** introduces a new function-like form of import that unlocks new capabilities compared to static import. This article compares the two and gives an overview of what’s new. V8 implementation

I assume you know the regular **import** syntax, It's cool, but you know, it's too static and strict, if you don't know about it, read [this](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import) to take the idea. We're gonna take a look at something like it in Next.js.

## Intro 👋

In this little article, I'm not teaching you about dynamic import, but I'll give some ideas about dynamic imports in **Next.js** specifically and You should know that I'm a learner like you, Maybe I'll say wrong things, So I expect you to correct them if I did.

For a review or introduction, We can implement dynamic import like this examples but It's a bad idea, I'll do just for your eyes:

```jsx
// 📁 say.js
export function hi() {
  alert(`Hello`);
}

export function bye() {
  alert(`Bye`);
}
// example from https://javascript.info/modules-dynamic-imports
// another file

// regular import 
import { bye, hi } from './say.js';
// dynamic import  
let { bye, hi } = await import('./say.js');
```

## Next

In Next.js, Where We use it? I don't know specifically, but I know some situations where I use it, For example:

* A huge component annoys us and slows us down in the loading of the page, So We can kick it with**dynamic import**, That means We load it after the initial loading page (lazily loading it), because We don't want the browser to waste its time on it. That means Next.js split our code into other manageable chunks. With this, We give the ability to load just the needed components.
* handling other huge files like perfect pictures with the same method.

Next.js implemented it in another and similar way, because [React.Lazy & Suspense](https://reactjs.org/docs/code-splitting.html) aren't ready for SSR or ... now. I think there are other reasons, And are.

The reason why I'm writing this article is that I had problems with [TTFB](https://web.dev/time-to-first-byte/) in the Blog that you are reading this article in, So I wanted to share here.

### Huge components

This Blog is a markdown blog, So We need a markdown engine, and inside the markdown, we use code samples and code samples need their syntax highlighter that needs to be passed to the markdown engine or component. Here is the point, The **markdown component** and **syntax highlighter** are too huge components, And when I used them regularly, They affect the TTFB (page loading), I used them like this:

```jsx
import ReactMarkdown from "react-markdown/with-html"; // 157.2 KB
import { Prism as SyntaxHighlighter } from "react-syntax-highlighter"; // 495.1 KB
```

Just see the size, It's crazy.
So, I learned about dynamic imports in Next.js, And I implemented it like this:

```jsx
import dynamic from 'next/dynamic'; // Next.js dynamic
// const Component = dynamic(() => import('Your component'),{...options})
const ReactMarkdown = dynamic(() => import('react-markdown/with-html'), { loading: () => '🐞...' });
const SyntaxHighlighter = dynamic(() => import('react-syntax-highlighter/dist/cjs/prism'));
```

In React we used React.Lazy syntax but in Next.js, it's a little bit different and We use dynamic instead and wrap the **import()** in it. There are some options for this method that We can use, like:

* **ssr**: Default is true, And if you make it false, the component will be handled in the client-side.
* **loading**: Show something when the component is in loading situation.

### Others

If you have huge image or something else too, you can handle it using just the **import()** or **require()**, We don't need *dynamic*, for example:

```jsx
<Image
        src={require(`../path/to/image.png`)}
        className='w-full'
    />
```

## Note

Don't be Obsessive like me, Sometimes you don't have a TTFB problem or huge components, So you don't need **dynamic import**, Imagine you are the browser, and someone thinks that you are too weak for handling 15 lines components, What you're going to do?
It's like using pure components or memo when you don't have any problem with React re-rendering.

I hope you enjoyed this small article and You know we don't have likes or comments here, but you can share it. If you wanted to tell me something, tell me in twitter or mention me anywhere else, You can create an issue in GitHub too. 🐞


In this little article, I'm not teaching you about dynamic import, but I'll give some ideas about dynamic imports in Next.js specifically ...

Next Dynamic imports

I woke up in the morning☕ days ago, I thought It will be a good day, but I checked GitHub and I found a package with Reoverlay name, I changed my thoughts because the day became an amazing day.
So, maybe You ask What… Why an npm package would make your day? It is a great question, if you’re curious about the answer, read this article.
One of the boring concepts in Front-end world and especially React is Modals and managing them.
to understand, Watch this example that I found it on Reoverlay Github:
```jsx 
const HomePage = () => {
  const [isDeleteModalOpen, setDeleteModal] = useState(false)
  const [isConfirmModalOpen, setConfirmModal] = useState(false)
  
  return (
    <div>
      <Modal isOpen={isDeleteModalOpen}>
        Code here...
      </Modal>
      <Modal isOpen={isConfirmModalOpen}>
		Code here...
	  </Modal>
      	Code here...
      <button onClick={() => setDeleteModal(true)}>Show delete modal</button>
      <button onClick={() => setConfirmModal(true)}>Show confirm modal</button>
    </div>
  )
}
```
Yea, Some Modal components, Some buttons for each Modal, Some states for Modals and buttons, It’s confusing.
Now, Imagine you have a bigger project, with more states, more Modals, more buttons, It will be a bad and inefficient way. It’s time to start with Reoverlay because everyone wants to change his life.
## Start
One of the reasons why we use Reoverlay is that it gives us new ways of managing Modals.
Reoverlay has two ways to manage Modals. Using the Components as arguments, or using configs as arguments, I prefer the second one, so we will use it.
First We need our App component like this:
```jsx 
import React from 'react';
import { Reoverlay, ModalContainer } from 'reoverlay';

import { AuthModal, DeleteModal, ConfirmModal } from '../modals';

// Here you pass your modals to Reoverlay
Reoverlay.config([
  {
    name: "AuthModal",
    component: AuthModal
  },
  {
    name: "DeleteModal",
    component: DeleteModal
  },
  {
    name: "ConfirmModal",
    component: ConfirmModal
  }
])

const App = () => {
  return (
    <>
      ...
      <Routes />
      ...
      <ModalContainer />
    </>
  )
}
```
In this simple way, In App.js We need to pass our config array to Reoverlay with config method. The config array must have an object with two properties: component name and the component itself.
We need to put the **ModalContainer** component because Modals will be there.
We can use component names in events later because we should pass the component names.
The benefit of this way is that We don’t need to import The modals everywhere, We just import all of them in the App component and pass them to Reoverlay config.
## Modals
Now take a look at ConfirmModal.js:
```jsx 
import React from 'react';
import { ModalWrapper, Reoverlay } from 'reoverlay';
// reoverlay css 
import 'reoverlay/lib/ModalWrapper.css';

const ConfirmModal = ({ confirmText, onConfirm }) => {

  const closeModal = () => {
    Reoverlay.hideModal();
  }

  return (
    <ModalWrapper>
      {confirmText}
      <button onClick={onConfirm}>Yes</button>
      <button onClick={closeModal}>No</button>
    </ModalWrapper>
  )
}
```
We have two props that We’ll pass them in other components. hideModal as its name, it is for hiding the modals.
## Last Step🙂
In this step, We want to show ConfirmModal component with clicking a button:
```jsx
import React from 'react';
import { Reoverlay } from 'reoverlay';

const PostPage = () => {
  
  const deletePost = () => {
    // showModal("Component name in config", props)
    Reoverlay.showModal("ConfirmModal", {
      confirmText: "Are you sure you want to delete this post",
      onConfirm: () => {
        axios.delete(...)
      }
    })
  }

  return (
    <div>
      <p>This is your post page</p>
      <button onClick={deletePost}>Delete this post</button>
    </div>
  )
}
```
In this component, We created a button for calling deletePost function. What does this function do? It uses showModal method from Reoverlay. This method takes two arguments, The **Modal component** name as the config we created in App.js component and the props of that Modal component. When we click the button, The confirmModal will become visible, And if we click “Yes”, Then axios.delete would be called.
## Let’s watch
code with few changes on codesandbox:
<iframe src="https://codesandbox.io/embed/suspicious-haslett-9fjb0?fontsize=14&hidenavigation=1&theme=dark"
     style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;"
     title="suspicious-haslett-9fjb0"
     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"
/>
I hope you liked the article, before going to bed, make sure to use Reoverlay.



I know you know that Modals managing is a pain.