Forem: Mohammad Bagher Abiyat

We Might Be Different Kind of Developers

Mohammad Bagher Abiyat — Tue, 05 Mar 2024 20:56:48 +0000

A while ago I tweeted this:

I was wondering where my FOMO (Fear Of Missing Out) comes from. There have been articles about React is this and that! A while after we hear about how's React Labs is going to change everything in React 19.

Then I see Qwikjs with all of the new improvements for the second version. Or I follow news around Solidjs, and I wonder how it's becoming the React I ever wanted. But after all, I'm like, there are too many options right now, I cannot even choose.

Next, I hear about the Local-first movement, and I suddenly decide to consider it for every application I'm going to write (spoiler alert: I don't write applications, mostly libraries)

The htmx discussion gets me to consider reading the htmx book. Honestly, I might not need to, but I'm just... curious.
Unjs keeps innovating every day, and it just skyrockets my FOMO around how I'm supposed to keep up with everything those folks build.

Wow, a new runtime just showed up, by amazon, which I haven't heard its name that much in the industry around me, except AWS. We also have pkl, by apple, which is a new way to do configuration. Next we have the serverless horror stories, now I'm thinking of self-hosting.

All these technologies take part of my mind every day, thinking about how I'm going to adopt them. Or If I should adopt them or not, trying to find reasons based on different circumstances.

Each of these technologies in itself is not confusing, instead they're all exciting, but all the mental burden building up makes the combination really confusing to me. How I'm going to combine each of these, that's the question I have every day, or as an open source developer, how I'm going to jump on the hype train, most importantly.

The Cure

I was trying to find a solution for this feeling, the FOMO. No solution yet to be honest.
Some may suggest removing twitter, but I enjoy it, it keeps me moving. All of that excitement, it comes with a cost, but at the end, each and every day I'm excited about all of that evolvement.

But when deeply looking into it, there might not be. I'm trying to find the best solution, that fits every situation. And that's exactly the mistake I'm making. I do not have a company that's worth million dollars. I don't even work in one, I'm just an open source developer. Finding the best tooling solution might not even make sense.
That's not the part of technology that's fun to me, maybe it's an age thing also, but I don't like finding the one-fits-all solution, I love exploring. Part of what made me enjoy this 5-4 years journey, is trying different things and finding out how they behave.

Me and the circle I'm in, the open source devs, the devs who watch the twitter news eagerly, follow youtube videos around what tool came up the other day, are a different kind of developers I reckon. We're not trying to find the "right" solution for our own company or the company we work in. Or the product we build. It's just trying different solutions that gets us the excitement. At least that's how I feel it is for my fellow developers.

So being confused about the different tools and getting the perfect combination, might not be bad after all! So even though I'm going to build a product soon, I won't choose the tool I used the last time I built a product. I would choose something more alternative that seems more interesting, like Nitro, because It's a backend-only solution that I feel it's going to be fun.

The last time I built a product (which failed), I used Qwikjs, and I cannot imagine how much I enjoyed it, but this time if I'm going to build a UI, I might try the Waku / RSC implementation, not because I'm a team member, I still find Qwikjs smoother as a server first UI library compared to RSC. But I want to wrap my head around RSC right now, because, it's just more interesting at this time and I'm more curious around it.

I think I might need to have a mindset shift, that this game for me at this point of my career should be fun after all, and not something strict that I have to bet it'd still behave the same in the next 10 years anyway. As I said, this might be absolutely wrong for other groups and niches of developers.

I'm trying to learn about writing and also experimenting with different ways of doing it! Let me know how do you feel about this one. Here's my Twitter.

Streams and React Server Components

Mohammad Bagher Abiyat — Sun, 14 Jan 2024 15:18:41 +0000

Many developers have used streams when building technology, but how many have truly understood their intricacies and their connection to React Server Components? Personally, the concept never quite clicked for me. It wasn't until contributing to Waku and being curious about how RSCs stream html—requiring me to take them seriously. Waku is a minimal layer over React Server Components using Vite.

In this essay, I'm going to talk more about the concept, the abstraction the Streams API provides around the concept and how React Server Components leverage this API.

Concept

data that is created, processed, and consumed in an incremental fashion, without ever reading all of it into memory. whatwg

Well, streams are a way of handling data sequentially! for instance, instead of reading the whole file into the memory which can exhaust the resources, you'd handle the file chunk by chunk (by dividing it).

const response = await fetch(url);
for await (const chunk of response.body) {
    // Do something with each small "chunk"
}

This saves memory, as you handle one chunk at a time instead of the whole file. Reading that file becomes almost instantaneous, as soon as your computer process the first chunk, it'd pass it to you without waiting for all the data to be processed.

A chunk is a single piece of data that is written to or read from a stream. It can be of any type; streams can even contain chunks of different types. whatwg

The web streams API, just provides a standard API for this concept, that not only handles files, but any form of data!

// All these methods embed the whole response in memory and return all of the results as opposed to response.body
response.blob()
response.text()
response.json()

RSC and `Transfer-Encoding: chunked`

While curious about how the React team streams the html, most Google articles referred to streaming videos with HLS (HTTP Live Streaming), which wasn't the desired information. It wasn't until I stumbled upon this mdn document.

This header means that the response I'm sending is divided into multiple chunks and we can add to those chunks in a non-blocking way after the initial response.
The key is that React just returns a stream (ReadableStream for edge, and a pipe method for Nodejs Streams ) and would let the server handle the rest!

In Nodejs or Cloudflare workers, the Transfer-Encoding: chunked header is set for the response since the response body is a stream.

RSC streaming an html document using a ReadableStream in Waku.

ReadableStream

// Fetch the original image
fetch("./tortoise.png")
  // Retrieve its body as ReadableStream
  .then((response) => response.body)

// https://developer.mozilla.org/en-US/docs/Web/API/Streams_API/Using_readable_streams#consuming_a_fetch_as_a_stream

It's a stream that you're supposed to read from, simple as that, and you cannot write (enqueue) to it unless you are the one who's providing the stream itself which you'll have access to an object called the controller at that point!

// you might want to open the console and try running this code
let controller;
const readable = new ReadableStream({
    start(c) {
        controller = c
    }
})

the start method runs when you instantiate the ReadableStream class and then you get the controller (ReadableStreamDefaultController).

controller.enqueue('chunk 1')
controller.enqueue('chunk 2')
controller.enqueue('chunk 3')
controller.close() // no more data

When receiving a ReadableStream from another source, like the fetch API, you won't have the ability to write data into it because you do not have access to the controller. Additionally, it makes sense, that you cannot modify a response coming from the server :)

Pull

Matteo highlighted the pull method as a better way to add data to readable streams, something I wasn't familiar with. The pull method is triggered when the consumer actively wants to receive data, unlike start, which activates when the readable stream is created.

In the earlier examples, data was added without considering if the consumer needed it. In such cases, the stream behaves like a push source. By using the pull method, we transform our stream into a pull source. This allows the stream to provide the necessary data only when needed. Here's an example.

Reader

For reading from a readable stream, we need a reader.

const reader = readable.getReader()

await reader.read()
// {done: false, value: 'chunk 1'}
await reader.read()
// {done: false, value: 'chunk 2'}
await reader.read()
// {done: false, value: 'chunk 3'}
await reader.read()
// {done: true, value: undefined}

what a reader does is lock the stream to itself so no other reader would read from the stream. I guess because it's jealous, just kidding 😄. The reason is that a stream handles one chunk at a time, and if we have two readers, those two readers might be at a different stage of reading (consuming) from the parent stream, or one of them might cancel the stream which would interfere with the other reader (consumer).

Teeing (`T`)

I won't go deep into this, but since we cannot have two readers from a single readable stream at the same time, we can tee that readable stream, creating two new readable streams that provide the same data. Teeing would force us to use either of those two new streams. And the original stream will be locked for them.

readable.tee()
// [ReadableStream, ReadableStream]

WritableStream

It's a stream you're supposed to write into (even if you don't have access to the controller), so it's the opposite of the ReadableStream.
But here's the catch, you can also read and track the values that are being written into this stream, but only if you are the one providing this stream. If you get to write data into this stream, you'll be called the producer.
It's usually a wrapper around the underlying sink which is a destination for the data, like the filesystem.
We have two ways of getting the data into a writable stream!

Readable Streams

When data flows into a readable stream, we can then pipe that stream into a writable stream. Like reading from the network (readable stream) and writing to a certain file on your disk (writable stream). The process that connects these two is called piping.

In a project like Waku, this approach is more common!

// readable: our readable stream from the previous example
readable.pipeTo(new WritableStream({
    write(chunk) {
        console.log(chunk)
    }
}))
// log: chunk 1
// log: chunk 2
// log: chunk 3

Writer

For readable streams, we've been able to lock the stream and read from it directly. The same goes for a writable stream, with writers we'll be able to write into a writable stream directly!

const writable = new WritableStream({
    write(chunk) {
        console.log(chunk)
        // imagine everytime we get a chunk, we write it directly to a file
    }
})

const writer = writable.getWriter()

writer.write('chunk 1')
// log: chunk 1
writer.write('chunk 2')
// log: chunk 2
writer.write('chunk 3')
// log: chunk 3

TransformStream

It's a stream that is mainly used for transforming the chunks we receive. It gives us two streams, one readable and one writable! We write into the writable, and the chunks will be processed (transformed) by the transform function that we pass the the TransformStream, and then whatever result will be enqueued to the readable stream. Without the transform function, it will just act as a bridge between writable streams and readable streams.

// https://streams.spec.whatwg.org/#example-transform-identity
const { writable, readable } = new TransformStream();

fetch("...", { body: readable }).then(response => /* ... */);

const writer = writable.getWriter();
writer.write(new Uint8Array([0x73, 0x74, 0x72, 0x65, 0x61, 0x6D, 0x73, 0x21])); // "streams!"
writer.close();

Here's a great example, where we pass a readable as the request's body, and then we write body content using a writer from the writable stream.

const { readable, writable} = new TransformStream({
    transform(chunk, controller) {
        controller.enqueue(chunk.split('').reverse().join(''))
    }
})
const writer = writable.getWriter()
const reader = readable.getReader()

await writer.write('olleh')
// 'olleh' -> transform() -> 'hello'
await reader.read()
// {done: false, value: 'hello'}

Here's an example of how you can reverse a string using the TransformStream!

`pipeThrough`

This is a method on readable streams that is useful for when we want to pipe the readable stream to the writable side of the TransformStream. And it'd return the readable side of the TransformStream.

const transformer = new TransformStream()

// instead of this
readable.pipeTo(transformer.writable)
// we can do this
readable.pipeThrough(transformer) // This would return transformer.readable

A typical example of constructing pipe chain using pipeThrough(transform, options) would look like. whatwg

// https://streams.spec.whatwg.org/#example-pipe-chain
httpResponseBody
  .pipeThrough(decompressorTransform)
  .pipeThrough(ignoreNonImageFilesTransform)
  .pipeTo(mediaGallery); // a pipe chain

Definitions

Internal queue

For readable streams, it's data that has been enqueued to the stream but hasn't been read by the consumer (a reader or another writable/transform stream).
For writable streams, it's the data that has been written to the stream itself but still hasn't been written into the underlying sink (file system for instance).

High water mark

The boundary for the amount of data that the stream can handle in the internal queue is called high water mark. If we cross that boundary, then backpressure would be applied.

Backpressure

A signal from the consumer stream to the parent stream slows the amount of data we receive (read or write), so we first handle the current data that we have in the current internal queue.

And that's it! The concept of Streams might mean different things in different contexts, but the core idea is handling small pieces of data sequentially, no matter if it's Video Streaming or React Server Components. The concept is not that complex but generating streaming-compatible data is the challenging part, and I guess that's why it took the React team years to reach what we call today React Server components.

I'm Mohammad and this is my first essay and post on my blog, would be happy to hear your thoughts. Don't hesitate to say hello in my DM! I'm also available for hire, so let's discuss that if you have an opportunity :)

Reviewers

Thanks to all of my friends who reviewed this document.

Resources

The useEffect Cheatsheet

Mohammad Bagher Abiyat — Fri, 09 Apr 2021 14:59:18 +0000

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

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

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)

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)

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)

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" 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.

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

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

// 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 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 or mention me anywhere else, You can even subscribe to my newsletter and follow me on Github.

Scheduling in web

Mohammad Bagher Abiyat — Fri, 26 Mar 2021 14:54:23 +0000

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.

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 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

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:

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.

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

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

For now, we need to create the schedule function.

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.

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 or mention me anywhere else, You can even subscribe to my newsletter and follow me on Github.

Next-generation web with isInputPending

Mohammad Bagher Abiyat — Tue, 16 Mar 2021 03:43:41 +0000

This post was originally posted on my personal blog.

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.

`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.

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.

 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.

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 or mention me anywhere else, You can even subscribe to my newsletter and follow me on Github. 👋🏻

isInputPending by web.dev

How JSX works?

Mohammad Bagher Abiyat — Thu, 11 Mar 2021 19:46:45 +0000

I put a post on my Twitter account and had a 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:

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:

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:

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 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:

// 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:

<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:

{
    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.

Big useEffect mistake

Mohammad Bagher Abiyat — Sun, 07 Mar 2021 15:54:47 +0000

This post was originally posted on my personal blog.

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:

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

Now if we do setStatemultiple times, we're going to see this in console:

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:

{ ...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:

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).

React Context without Provider + useMutableSource

Mohammad Bagher Abiyat — Wed, 24 Feb 2021 17:26:59 +0000

This post was originally posted on my personal blog.

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 (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.

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

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 and Twitter; 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:

 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.

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.

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 the 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); // [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:

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.

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.

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 or mention me anywhere else, You can even subscribe to my newsletter.

Cover image: Experiment, Nicolas Thomas, unsplash

A wild ride in my 16th year

Mohammad Bagher Abiyat — Mon, 15 Feb 2021 15:04:02 +0000

This post was originally posted on my personal blog.

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, 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; 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, 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'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 (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'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, 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 for bringing me into contributing javascript libraries.

Hacktoberfest

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

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

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.

Writing✏️

The best way of learning is teaching, that's weird, but that's how it is. I started writing stuff because swyx'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. 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.

Poimandres

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, 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.

Cover image: Fuji-Q Highland, Priscilla Du Preez, unsplash

Javascript dynamic imports + Next.js

Mohammad Bagher Abiyat — Wed, 10 Feb 2021 10:42:10 +0000

This article was originally posted on my personal blog.

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 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:

// 📁 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');

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 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 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:

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:

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:

<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 don't forget to share, and reaction to my article. If you wanted to tell me something, tell me on Twitter or mention me anywhere else. You can subscribe to my newsletter too on my blog.

Cover picture by Tanya Pro on Unsplash

Tree shaking goodness

Mohammad Bagher Abiyat — Tue, 09 Feb 2021 04:35:06 +0000

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

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 or Rollup 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:

// meet.js
function hi() {
    ...
}
function bye() {
    ...
}

export { bye, hi }

Now import it in another file:

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.

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.

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, 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.

How to read open source js libraries

Mohammad Bagher Abiyat — Sat, 06 Feb 2021 14:33:42 +0000

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 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 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 extension. I just need to create a config file there.

// .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.

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. Don't forget to take a look at my blog for exclusive articles there.

Forem: Mohammad Bagher Abiyat

We Might Be Different Kind of Developers

The Cure

Streams and React Server Components

Concept

RSC and Transfer-Encoding: chunked

ReadableStream

Pull

Reader

Teeing (T)

WritableStream

Readable Streams

Writer

TransformStream

pipeThrough

Definitions

Internal queue

High water mark

Backpressure

Reviewers

Resources

The useEffect Cheatsheet

Philosophy

Dependencies

Each Render Has Its Own Effects

Scheduling in web

Scheduling 🤩

Next-generation web with isInputPending

Does it matter? 🤔

isInputPending()

How does it work?

How JSX works?

Prerequisites

Magic

Let's be a magician

Big useEffect mistake

The mistake 😮

React Context without Provider + useMutableSource

Why a new one?

Tearing

Experimental, Why should I use it?

Context with no Provider

Start

useContext

A wild ride in my 16th year

2020🧛🏻

The beginning

Svelte vs React🤔

So Svelte

React😮

Open-source😌

Hacktoberfest

Carbon

Jotai

Writing✏️

Poimandres

Javascript dynamic imports + Next.js

Intro 👋

Next

Huge components

Others

Note

Tree shaking goodness

Why? 🤔

How? 😬

Note

How to read open source js libraries

Needs

Start

Settings

Breakpoints

RSC and `Transfer-Encoding: chunked`

Teeing (`T`)

`pipeThrough`

`isInputPending()`

`useContext`