
When I started ReactJS, I really enjoyed my first steps, component, props and many fun things about react. One of that features was `useEffect`; it was fun but complicated for me while I struggled to learn it. 

Now I want to share my mental model in this small cheat sheet to help you learn `useEffect` better or own a better mental model. 

## Philosophy

> `useEffect` is not a lifecycle hook. It's a mechanism for synchronizing side-effects (`fetch`, `setTimeout`, ...) with the state of your app. [EpicReact.dev](https://epicreact.dev/myths-about-useeffect)

The main goal is not using `useEffect` for the component lifecycle but using it to do stuff when state-changes (re-renders).

```jsx
useEffect(() => {
  // A: run whenever the deps changes
  return {
	  // B: Optional, runs before 1, we call this the clean-up function
  }
}, deps); // deps is Optional too
```

`useEffect`'s running steps:

- 1: Run A
- 2: Wait for new state changes (component re-renders)
- 3: If the `deps` changed
    - Run B to cleanup the previous render's side-effects
    - Go to 2

## Dependencies

- **No dependency**: the side-effect function (A) will run on every state-change (re-render)

```jsx
useEffect(() => {
  // I depend on everything, I'll run on every re-render
}); 
```

- **Empty Array**: There's nothing to listen to its changes, so it'll run the side-effect function just one time at the state initialization (first render)

```jsx
useEffect(() => {
  // I depend on nothing, I'll run just one time
}, []);
```

- **Non-Empty Array**: The side-effect function runs on every dependency changes (at least one of the dependencies)

```jsx
useEffect(() => {
  // I depend on state1, state2 and prop1
  // I'll run on every change of these dependencies
}, [state1, state2, prop1]);
```

## Each Render Has Its Own Effects

I really love the "[Each Render has its own Effects](https://overreacted.io/a-complete-guide-to-useeffect/#each-render-has-its-own-effects)" title; I think almost all hooks rely on that title. We should note that every render has its own function body and its own values. The same goes for the side-effect function; check this.

```jsx
useEffect(() => {
  console.log(count)
}, [count]);
```

let's do some fake state changes and see what happens to the side-effect function.

```jsx
// in the first render, `count` is 0
// The side-effect function is going to be like this
() => {
  console.log(0)
}
// assume we change `count` to 1 (setCount(1)), next render is like that
() => {
  console.log(1)
}
// and so on...
```

That's how `useEffect` works around dependencies.
- [PDF](https://github.com/Aslemammad/Cheatsheets/blob/master/useEffect.pdf) on GitHub

I hope you enjoyed this Cheatsheet. Don't forget to share and send reactions 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) and follow me on [Github](https://github.com/Aslemammad).

When I started ReactJS, I really enjoyed my first steps, component, props and many fun things about react. One of that...

The useEffect Cheatsheet


Imagine doing 10 tasks continuously; maybe we don't get tired after those 10 tasks, but how about 50 tasks or 100 tasks? We cannot even do this amount of tasks continuously.

But there's one solution for that, and that's **scheduling**. With scheduling, we can do any amount of tasks easily, and we're going to increase our productivity. For example, After every 10 tasks, we take a rest for 5 minutes, or better than that, we can keep doing tasks until we get tired, then we take a rest and continue doing the rest of the tasks. 

The same goes for javascript, For example, this code will block our thread for 5 seconds, and everything will stop working.

```tsx
let current = Date.now()
while (Date.now() < current + 5 * 1000) {
	console.log(`I'm blocking your thread for 5sec`)
}
```

But that's not fair, because it's not heavy work. Libraries like Reactjs can handle 100x heavier work without blocking the browser. The reason is that such libraries use scheduling.

## Scheduling 🤩

Scheduling is about:

- *work queue*: list of works that we want to schedule and get done
- *[micro & macro](https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide) tasks*: two different kinds of tasks which we can move our own tasks into one of these phases, so the browser's going to handle it later(micro task) or immediately(macro task or task)

> First, each time a task (macro task) exits, the event loop checks to see if the task is returning control to other JavaScript code. If not, it runs all of the microtasks in the microtask queue. The microtask queue is, then, processed multiple times per iteration of the event loop, including after handling events and other callbacks. [*developer.mozilla.org*](http://developer.mozilla.org/)

Now it's time to schedule some stuff, let's see.

First of all, imagine we have many expensive work units in our work queue, like this:

```tsx
function expensive() {
  console.log('I wanna block the event loop')
}
const workQueue = new Array(1000000).fill(expensive); // [expensive, expensive, ...]
// 1000000 amount of work units 🤯🤯
// workQueue.map(job => job()) will destroy the event loop and everything will stop working
```

If we want to schedule these units, we have to consider two things: a *deadline* for running the units. If it's done, we yield to the browser to handle the user input events and then return to run the rest of the units; second, a user input event (clicking, typing, ...) happened when running the units, so we yield back immediately to the browser again, for checking if we have user input events, we use [isInputPending](https://bugged.dev/post/Next-generation-web-with-isInputPending).

Let's set the deadline time, which I prefer setting it as one frame.

```tsx
const DEADLINE_TIME = 1000 / 60 // 1000ms / 60frames
```

For now, we need to create the `schedule` function.

```tsx
function schedule() {
  const DEADLINE = performance.now() + DEADLINE_TIME;
  while (workQueue.length > 0) {
    if (navigator?.scheduling?.isInputPending() || performance.now() >= DEADLINE) {
      // Yield to the browser if we have to handle an input event, or we're out of time.
      setTimeout(schedule); // re-running the schedule function later as a macro task
      return; // stop
    }
	// execute the current work unit 
    let job = workQueue.shift();
    job();
  }
}
```

So if we have a user input event waiting or we're out of time, we put our `schedule` function on a different part of the event loop (`setTimeout`), so the browser can handle the input event and other things that sit before it; after that, It's going to re-run it and let the `schedule` function execute the rest of the units if possible.

Now, if you try running the `schedule` function, 1 million logs will not stop everything from working, and everything's going to work well.

```tsx
schedule()
```

That's it, easy and fast like that.

I hope you enjoyed this article. Don't forget to share and send reactions 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) and follow me on [Github](https://github.com/Aslemammad).

Imagine doing 10 tasks continuously; maybe we don't get tired after those 10 tasks, but how about 50 tasks or 100 tasks?

Scheduling in web


As we know, almost everything in javascript gets done in a single thread, which gives us a unique model of controlling our work in the browser. With a single thread, I mean when we put an infinite loop in our code, it's going to block our page from doing other works, and everything's going to stop suddenly. 

## Does it matter? 🤔

That's why we say javascript does one thing at a time, and it's not a parallel language. For example, we have two ways to optimize our code for the user in the browser; first, we can complete all of the works we have and get them done, then we're going to listen for the user's interactions (events), which prevents the user from interacting with the page for seconds (maybe less) sometimes, but it has a fast load time.

The second way is responding fast, which we split our code into blocks and schedule/run them (I'll explain scheduling in the next article). After getting done every block, we yield to the browser to check if there's a chance of having user/browser events to respond to; thus, we can respond to the user faster, but we'll have a slower load time, and that's how many frameworks/libraries work. 

![Load fast or respond fast, by web.dev](isInputPending1.png)



## `isInputPending()`

But what if we check if there is a waiting event without yielding to the browser. Yes, it's now possible with the experimental `isInputPending`. As you saw, without `isInputPending`, after every block of work, we yielded to the browser compulsory without knowing even if we have a pending event or not. But with `isInputPending`, there's no need to yield to the browser like a loop; instead, we check if there's a pending input, we yield; if not, we'll go to the next job/task. So we're going to have both fast loading and fast responding at the same time. 

![isInputPending, by web.dev](isInputPending2.png)

## How does it work?

Let's create an example to see how it works and when we're going to use it.

> `isInputPending` is an experimental tool, so I don't recommend using it now, and in the future, it's going to help frameworks/libraries schedulers. So it's for packages more than personal/business uses.

Assume we have a huge to calculate function called `expensive`, And we're going to run it without breaking the web page.

```jsx
 function expensive() {
  /* Some expensive calculations */
}
function calculate() {
  if(navigator.scheduling.isInputPending()) {
    /* 
      if there's a pending input, yield to the browser, 
      cancel the operation, and put the function in another part of the event loop,
      to check and run it again if it's possible (if there's no pending input)
    */
    setTimeout(calculate, 0)
  }
  // if there's no pending input, run the expensive function
  expensive();
}
calculate();
```

That's it, and that's how we're going to be performant and fast in the future.

> To learn more about event loop and zero delays setTimeout, Check out [this](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop#zero_delays).

I hope you enjoyed this article and learned something new. Don't forget to share and send reactions 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) and follow me on [Github](https://github.com/Aslemammad). 👋🏻

* isInputPending by [web.dev](https://web.dev/isinputpending)

As we know, almost everything in javascript gets done in a single thread, which gives us a unique model of controlling our work in the browser. With a single thread...

Next-generation web with isInputPending


> I put a [post](https://twitter.com/asleMammadam/status/1369633033737928712) on my Twitter account and had a little brief talk on how jsx works, So I want to explain more about it here.

Every ReactJS developer knows about the jsx magic, it let us write some HTML in javascript, and that's how the magic happens. We can do this kind of stuff in tools like babel.

For example, we have a babel plugin named `@babel/plugin-transform-react-jsx` that gives us the ability to work with JSX syntax.

## Prerequisites

We just need `@babel/plugin-transform-react-jsx` to start, you can install it with npm or yarn:

```bash
npm install --save-dev @babel/plugin-transform-react-jsx
# or
yarn add -D @babel/plugin-transform-react-jsx
```

## Magic

It's the time to dig into the magic and see what happens inside. In React 17, React core team replaced the classic `React.createElement` with the `jsx` and `jsx` functions, so you don't need to import React anymore to write jsx. Now, the `@babel/plugin-transform-react-jsx` uses the `jsx` function by default now, check out this: 

```jsx
const profile = (
  <div>
    <img src="avatar.png" className="profile" />
    <h3>{[user.firstName, user.lastName].join(" ")}</h3>
  </div>
);
```

By default, babel is going to compile that jsx to this plain javascript:

```jsx
import { jsx as _jsx } from "react/jsx-runtime";
import { jsxs as _jsxs } from "react/jsx-runtime";

const profile = _jsxs("div", {
  children: [
    _jsx("img", {
      src: "avatar.png",
      className: "profile",
    }),
    _jsx("h3", {
      children: [user.firstName, user.lastName].join(" "),
    }),
  ],
});
```

That's how the magic works, easy as that!

## Let's be a magician

We all love to do magical things, why we don't do it now, so let's do it! We need that babel plugin to do some magic. 

Now we can tell the plugin to use our own function instead of react's functions. For that, we need to write a small comment to tell it.

```jsx
/** @jsx logJsx */
```

Here we tell it, we want to use `logJsx` for jsx syntax. For the `logJsx` function, we turn the jsx into a logged statement like "It's a div, Hello Mohammad". Now let's define the `logJsx` function:

```jsx
// the babel plugin is going to pass this function the type and props/attributes 
function logJsx(type, props) {
  console.log(`It's a ${type}, Hello ${props.name}`);
}
```

We did it, check this:

```jsx
<title name="Mohammad"></title> // type: "title" props: { name: "Mohammad" }
// console: It's a title, Hello Mohammad
```

That's how jsx works, but in React, instead of logging, it gives us an object like this:

```jsx
{
    type: "title",
    key: null,
    ref: null,
    props: {
        name: "Mohammad"
    },
    _owner: null,
    _store: {}
}
```

Now we saw what's going on underneath in React. If you know any other magic, comment it or mention me on Twitter and tell me about it. 

I hope you enjoyed this article and learned something new. Don't forget to share and send reactions 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) and follow me on [Github](https://github.com/Aslemammad). 👋🏻

Every ReactJS developer knows about the jsx magic, it let us write some HTML in javascript, and that's how the magic happens. We can do this kind of stuff in tools like babel.

How JSX works?


In Reactjs, we encountered infinite loops or useless re-rendering a lot. It's something unavoidable, but we can be more attentive about it sometimes. One of the reasons that cause us this kind of problems is useEffect; I'm going to talk about one of the mistakes we can make with it and learn how to be aware of it.

## The mistake

Check this out:

```tsx
const [state, setState] = React.useState(0);
React.useEffect(() => {
  console.log("re-rendering");
}, [{ ...someData }])
```

Now if we do `setState`multiple times, we're going to see this in console:

```tsx
re-rendering
re-rendering
re-rendering
```

Wait; what? We just passed `someData` as a dependency list; why it logs that? That's not even related to `state`. Yes, it's not related, but pay more attention to the dependency list; We passed an inline object, which means it's always different from its previous version; we create it every time we cause a re-render to the component. Check this:

```tsx
{ ...someData } === { ...someData } // false
{} === {} // false
[] === [] // false
// all are inline and have different references
```

`useEffect` somehow cache the dependency list and check if it's equal to the next value. That's why inline non-primitive values (`[]`, `{}`, `{...data}`, ...) are always different in this tool's eyes.

> `Symbol()` is an exception here, it's different every time we create it, but it's a primitive value.

For example, check this, I saw many developers that they check part of an array like this:

```tsx
const [state, setState] = React.useState([1, 2, 3, 4, 5]);
React.useEffect(() => {
  console.log("re-rendering");
}, [state.slice(0, 2)]); 
/* 
	prevVal = state.slice(0, 2) // first render
		***
	nextVal = state.slice(0, 2) // second render
		***
	prevVal === nextVal // false
*/
```

The expected behaviour is checking 1 to 3 values, but it doesn't work like that because the `slice` method will always return a new array (reference).

I hope you enjoyed this article. Don't forget to share and send reactions 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) and follow me on [Github](https://github.com/Aslemammad).

In Reactjs, we encountered infinite loops or useless re-rendering a lot. It's something unavoidable, but we can be more attentive about it sometimes.

Big useEffect mistake

![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.

Bugged🐞