Forem: Anas Mustafa

From PreReact to React and Next.js A Journey Through Web Rendering and Performance Optimization

Anas Mustafa — Thu, 03 Oct 2024 21:13:58 +0000

In this article, we'll explore the origin of React, what problems it solves, and

why Next.js was created. While it's widely known that Next.js offers SSR (server-side rendering), we'll dive deeper into what SSR truly is and why it might be better than CSR (client-side rendering) in certain cases.

A Brief History: Before React.js

Before React.js popularized the concept of CSR (client-side rendering), most applications followed the traditional MPA (multi-page application) model. In MPAs, the server handled the rendering of HTML, a process that we will see had both advantages and drawbacks.

As we can see, rendering the page was simple. You send a request to the server, it takes some time to set up the necessary HTML, sends it back, and yay the page is loaded.

So, what's the problem? At this stage, there isn't one. In fact, this approach can seem more efficient than how React.js handles page loading—at least initially. However, the problem arises when users start interacting with the page. Let's walk through a hypothetical scenario:

You enter a page.
You log in (client -> server (for authentication) -> DB (check for user)) and back. No problem here.
You navigate to, say, the posts page (client -> server -> DB (get posts)) and back with the post data. No problem here.
Create a new post (client -> server (with new post) -> DB (add new post)) and back with a completely new HTML. Here’s where the problem arises. When you add a new post—or make any changes to the page—the server needs to re-render the entire HTML from scratch. This results in a full page re-render, which can be inefficient. This full re-render occurs anytime you update or change anything on the page.

that's was what react was trying to fix

Now Enter React.js

How did React fix the problem?

React introduced the revolutionary concept of client-side rendering (CSR). Instead of rendering the HTML on the server, CSR renders it on the client’s browser.
But how does this work?, given that when you first load the page, the server still has to serve HTML?

Here’s what happens: the server sends an initial HTML skeleton, but it doesn’t contain the actual content. Instead, it includes a <script> tag that links to the bundled JavaScript code. When the HTML is loaded—which happens quickly since it’s mostly empty—React takes over, rendering the actual content on the client. However, the content isn’t immediately available. React first has to make a separate request to the server to fetch the necessary data. Only after this process is complete will you see the full page.

As you can see, it’s a bit more complex than traditional server-side rendering (SSR) in multi-page applications (MPAs). In fact, it might seem slower initially because it requires multiple round trips to the server—first for the HTML skeleton, then for the JavaScript file, and finally for the data. This is one of the trade-offs React accepted for tthe magic that comes next.

Now, let’s return to the step where the browser loads the JavaScript from the <script> tag in the initial HTML. What React actually does is create a virtual copy of the DOM, known as the Virtual DOM (VDOM). React uses this VDOM to efficiently track changes. Instead of re-rendering the entire HTML page from the server every time something changes, React uses a process called reconciliation.

Reconciliation:

React compares the current state of the DOM with its virtual counterpart to pinpoint exactly where the changes occurred. It then updates only the parts of the DOM that have changed, instead of reloading the entire page.

Now, that's amazing! React has solved the problem by allowing you to track changes in the DOM and only update the parts that have changed—all on the client side—without needing to make multiple trips to the server.

However, this solution comes with some trade-offs:

Client-side resource usage: The client’s computer is now responsible for rendering the HTML, creating the Virtual DOM, and handling the reconciliation process. This can be time-consuming, especially with large tree structures.
Limited visibility for bots and crawlers: Bots and crawlers—such as those from Facebook, X (formerly Twitter), or Instagram—may have difficulty parsing content in pure client-side rendered applications. This occurs because these bots typically don't execute JavaScript, meaning they can only see the initial HTML that the server sends, which is often blank or minimally populated. This can impact SEO or social media sharing if the content relies heavily on client-side rendering.

The key challenge here is balancing client-side interactivity and server-side efficiency. Suppose we could return to having the server render the initial HTML (complete with the necessary data) while still leveraging React’s reconciliation and virtual DOM features for client-side updates. In that case, we’d have the best of both worlds.

If only there were a framework...

Now Enter Next.js

This is where Server-Side Rendering (SSR) and frameworks like Next.js come into play. Next.js allows developers to render pages on the server first, ensuring the initial HTML includes all the data the user needs, improving performance and SEO. After this initial server-rendered page is sent to the client, you get the full HTML content, but the page is not interactive yet—React hasn’t been loaded. Once the JavaScript loads, React undergoes a hydration process.

Hydration is when React takes over the pre-rendered HTML on the client-side, enabling smooth interactions and updates through React’s Virtual DOM and reconciliation process.

React Performance Optimization Techniques Part 1

Anas Mustafa — Sat, 28 Sep 2024 04:19:13 +0000

React is a powerful library for building user interfaces, known for its extensive ecosystem, large community, and flexibility in building complex and dynamic applications. One of its core features is the Virtual DOM, which helps React efficiently manage UI updates.

The Virtual DOM is an in-memory representation of the real DOM. When the state of a component changes, React compares the current Virtual DOM with a previous snapshot to detect differences. This allows React to only update the parts of the real DOM that have changed, improving performance. However, in larger applications with complex component trees, frequent re-renders can become computationally expensive, as React must recreate and compare the Virtual DOM each time a state change occurs.

To mitigate the performance cost of unnecessary re-renders, React provides several optimization techniques that allow developers to improve the efficiency of their applications.

There are several techniques to improve React performance, and below is a list of those that are effective and can be applied to any application:

list virtualization
lazy loading images
memoization
throttling events
debouncing events
code splitting
React fragments
useTransition hook
web workers

In this article, I will focus on the first three techniques: list virtualization, lazy loading images, and memoization. In my next article, I will explore the remaining topics, except for web workers, as I have already written a detailed article on that subject, which you can find here: Web Workers.

Now, let's dive into how these techniques can enhance performance, starting with list virtualization.

1. list virtualization

Rendering a large list is expensive, not only during the initial load time, as React has to render the entire list before displaying the UI. This is where list virtualization comes into play.

Consider this: why load the entire list at once if the user can only see a small portion of it due to screen size? Instead of rendering the entire list, we can render only the visible portion and load more items as the user scrolls. This is exactly what list virtualization does—only rendering the items that are currently in view, significantly improving performance for large lists.
this feature is used by most of social media apps like facebook, x and instegram.

In the image above, you can see how X (formerly Twitter) effectively renders an infinite number of posts by only displaying a fixed number at a time. This is achieved through list virtualization.

To implement list virtualization in React, we can use one of two libraries: react-window or react-virtualized, both created by the same author. In this case, we will use react-window due to its simplicity.

I will demonstrate how to implement it using react-window and also show the difference with a regular map implementation.

install the library

# Yarn
yarn add react-window

# NPM
npm install --save react-window

In this example, we use the AutoSizer component to ensure the list takes up all available space:

import { FixedSizeList as List } from "react-window";
import AutoSizer from "react-virtualized-auto-sizer";
import "./styles.css";

export const Window_List = () => {
const Row = ({ index, style }: { index: any; style: any }) => (
<div className={index % 2 ? "ListItemOdd" : "ListItemEven"} style={style}>
Row {index} 
</div>
);
return (
<AutoSizer>
{({ height, width }: { height: any; width: any }) => (
<List
className="List"
height={height}
itemCount={1000}
itemSize={35}
width={width}
>
{Row}
</List>
)}
</AutoSizer>
)};

You can see that the load time is not significantly affected when using list virtualization, which is expected since only the visible items are loaded initially.

here a list without virtualization

export const List = ({ count }: { count: number }) => {
return (
<ul className="uList">
{
new Array(count).fill(null).map((_, index) => {
    return (
        <>
            {index % 2 ? (
            <li className="item odd_item">Row {index}</li>
            ) : (
            <li className="item even_item">Row {index}</li>
            )}
        </>
    );
}
)}
</ul>
);
};

You can see that the load time is significantly longer when dealing with a normal list, which increases exponentially as the number of items grows.

Important: Use list virtualization only when handling large lists. While it minimizes loading time, the application still needs to update the screen with new data as the user scrolls, which means rendering additional components.

2. lazy loading images

Lazy loading is a technique used to defer the loading of off-screen images until the user scrolls near them. This helps improve the initial page load time by only loading the necessary resources upfront, and deferring others until they are needed. This can greatly enhance the performance and user experience of your application, especially when dealing with media-heavy pages.

In React, lazy loading can be implemented efficiently using the native loading="lazy" attribute for images, or by using more advanced techniques like Intersection Observer for customized control over when and how images load.

Why Use Lazy Loading?

Improved performance: Lazy loading images can significantly reduce the initial page load time, especially on pages with many images. Only images that are visible in the viewport are loaded immediately, reducing the number of requests and the amount of data loaded initially.
Better user experience: Faster initial load times lead to a smoother and more responsive experience for users, particularly on slower networks or less powerful devices.
Bandwidth savings: Lazy loading helps save bandwidth by only loading images that the user actually scrolls to, preventing unnecessary data usage. #### Without Lazy Image:

When images are not lazily loaded, they are all fetched as soon as the page loads, even if they are off-screen and not immediately visible to the user. This can significantly increase the initial page load time and affect performance, especially if your page contains many images or large media files.

In the above example, all images are being loaded upfront, causing delays in rendering the entire page.

Basic Example: Lazy Loading with `loading="lazy"`

The simplest way to implement lazy loading in React is by using the loading="lazy" attribute on the <img> tag. This attribute tells the browser to defer loading the image until it's needed.

In this example, the browser will automatically lazy load the images as the user scrolls down, without requiring any additional JavaScript.

Advanced Example: Lazy Loading with Intersection Observer

For more control over the lazy loading behavior, you can use the Intersection Observer API. This API allows you to observe when an element enters or exits the viewport, and can be used to lazy load images only when they are about to be displayed on the screen.

In this example, the LazyImage component uses the Intersection Observer API to detect when the image enters the viewport. When the image is about to be visible, it loads the image source (src). Otherwise, it displays a placeholder, optimizing both performance and user experience.

Conclusion

Lazy loading images can greatly improve both performance and user experience by deferring the loading of off-screen images until they're needed. Whether using the native loading="lazy" attribute or a more advanced custom solution with Intersection Observer, lazy loading is a simple yet powerful optimization technique for modern web applications.

3. memoization

Memoization is a powerful optimization technique, and the name comes from "memo," which refers to saving something for later use. In React, memoization helps by caching the results of computations or function calls so that they are not repeated unnecessarily. This improves the overall performance of your application by avoiding redundant re-renders and recalculations.

In React, memoization can be achieved in three main ways, each offering unique capabilities:

useMemo

memo

useCallback

1. useMemo

The useMemo hook allows you to cache the result of a function call, making it available for later use without recalculating.
When you call a function for the first time, useMemo executes it normally. However, on subsequent calls with the same dependencies (input values), it simply returns the cached value, thus saving computation time.

This is particularly useful when the function is computationally expensive, as it prevents the costly operation from being executed on every render unless necessary.

u can find full code here

here u can find code for normal function call

const [a, seta] = useState("");
const [b, setb] = useState("");

function do_something(a: string, b: string) {
    console.log("do_something called");
    return a + b;
}
return (
<button
    onClick={() => {
        console.log(do_something(a, b));
    }}
    className="button">
    Click Me
</button>
);
}

In the previous example, the "do_something called" message is printed every time the button is clicked, even though the parameters a and b haven't changed. This shows that the function do_something is recalculated on every render, which is not ideal when working with expensive computations.

By using the useMemo hook, we can memoize the result of the function call and ensure that do_something only runs when a or b changes, rather than on every click.

Here's how useMemo solves this problem:

const [a, seta] = useState("");
const [b, setb] = useState("");

function do_something(a: string, b: string) {
    console.log("do_something called");
    return a + b;
}
const memo_do_something = useMemo(() => do_something(a, b), [a, b]);
return (
<button
    onClick={() => {
        console.log(memo_do_something);
    }}
    className="button">
    Click Me
</button>
);
}

In this updated code:

The function do_something is now memoized using the useMemo hook.
The "do_something called" log is only printed when the values of a or b change. On subsequent clicks, the memoized value is reused, avoiding the need to recalculate the result.
- you would notice that the "do_something called" is not printed when u click the button as it uses the cashed value, it instead printed when the states in the dependency array change [a,b]. ##### Key Takeaways:
useMemo helps to prevent unnecessary recalculations by memoizing the result of expensive functions.
It will only recompute when one of the values in the dependency array ([a, b]) changes, making it ideal for performance optimization in large applications.

2. Memo

React.memo is a higher-order component (HOC) used to memoize functional components. It ensures that a component only re-renders if its props change.

This is particularly useful for components that receive the same props frequently but don't need to re-render.

lets build a small example to show how React.memo can be useful
down here u can see the virtual dom structure of the project

In this example, we have an App component that renders two child components: Child_1 and Child_2. Inside Child_1, there is another nested component, Child_1_1. Each of these components receives a prop (prop), and we trigger a re-render by updating the state (variable) through a button click.

Behavior without `React.memo`:

Every time the variable is incremented in App, all child components (Child_1, Child_2, and Child_1_1) are re-rendered, even though their props do not change.
This is unnecessary and can degrade performance in larger applications since React re-renders components even when they receive the same props.

u can find full code here

function App() {
    console.log('App rerender');
    const [variable, setVariable] = useState(0);
    return (
    <>
        <button
            onClick={() => {
                setVariable((old) => old + 1);
            }
        }>  
            increment
        </button>
        <Child_1 prop={555} />
        <Child_2 prop={555} />
        </>
    );
}
export const Child_1 = ({ prop }: { prop: any }) => {
    console.log(`child_1 rendered`);
    return (
        <div
            <Child_1_1 prop={555} />
        </div>
    );
};
export const Child_2 = ({ prop }: { prop: any }) => {
    console.log(`child_2 rendered`);
    return <div></div>;
};
export const Child_1_1 = ({ prop }: { prop: any }) => {
    console.log(`child_1_1 rendered`);
    return <div></div>;
};

In the GIF, every time the button is clicked, all components rerender, even though the prop values of Child_1, Child_2, and Child_1_1 haven't changed. This results in unnecessary renders.

Introducing `React.memo`:

To prevent unnecessary re-renders, we can wrap these child components with React.memo. This ensures that they only re-render when their props change, reducing the overall rendering load.

export const Child_1 = memo(({ prop }: { prop: any }) => {
    console.log(`child_1 rendered`);
    return (
        <div
            <Child_1_1 prop={555} />
        </div>
    );
});
export const Child_2 = memo(({ prop }: { prop: any }) => {
    console.log(`child_2 rendered`);
    return <div></div>;
});
export const Child_1_1 = memo(({ prop }: { prop: any }) => {
    console.log(`child_1_1 rendered`);
    return <div></div>;
});

In the GIF after introducing React.memo, when you click the button, only the App component re-renders. Neither Child_1, Child_2, nor Child_1_1 re-renders since their props remain unchanged.

Conclusion:

By using React.memo, you prevent unnecessary re-renders of child components when their props remain the same. This technique is particularly beneficial in applications with complex component hierarchies or expensive re-renders, as it helps optimize performance by avoiding redundant renders. However, it's important to note that React.memo should only be used when needed, as overusing it can sometimes introduce complexity without much benefit.

3. useCallback

The useCallback hook allows you to cache the function definition itself, which means React will not recreate the function on every render unless the specified dependencies change.

Why is this useful?

Function recreation on every render: In React, functions inside components are redefined each time the component re-renders. This means even though the function's logic hasn’t changed, React will treat it as a new function. If you pass such a function as a prop to child components, React will think the prop has changed and unnecessarily re-render those child components.
Prevent unnecessary child component re-renders: By caching the function definition with useCallback, React ensures that the function reference remains the same until its dependencies (usually state or props) change. This prevents child components from being re-rendered unnecessarily.

Example: Using `useCallback` to Prevent Unnecessary Re-renders

In the previous example, let's modify the Child_1 component to accept a function as a prop, which will help us demonstrate the useCallback hook.

Before Using `useCallback`

function App() {
    console.log('App rerender');
    const [variable, setVariable] = useState(0);
    function do_something () {
        console.log('do_something is called');
        return 'hello world';
    }
    return (
        <>
            <button
                onClick={() => {
                setVariable((old) => old + 1);
                }}>
                increment
            </button>
            <Child_1 prop={do_something} />
        </>
    );
}
export default App;

In this example, Child_1 re-renders every time App re-renders, even though the function do_something hasn't changed. This happens because do_something is redefined on every render of App, causing React to think the prop passed to Child_1 has changed.

Solution: Using `useCallback`

By using the useCallback hook, we can cache the do_something function to avoid its recreation on each render, thus preventing Child_1 from re-rendering unnecessarily.

// change do_something to
const cashed_do_something = useCallback(function do_something() {
    console.log("do_something is called");
    return "hello world";
}, []);
// update prop
<Child_1 prop={cashed_do_something} />

With useCallback, React will cache the cashed_do_something function, and Child_1 will only re-render when the dependencies of useCallback (in this case, none) change. This optimizes the rendering process, reducing unnecessary renders of Child_1.

Conclusion

Using useCallback is an effective way to avoid unnecessary re-renders caused by passing newly created function references to child components. This hook is particularly beneficial in applications where performance is a concern, especially when dealing with deeply nested component trees or passing functions as props frequently.

Why the Streams API is a Game-Changer for Web Developers

Anas Mustafa — Sun, 15 Sep 2024 17:50:42 +0000

Let's start by explaining how data is sent over the web. It is not sent as a single continuous stream; instead, it is divided into smaller chunks. On the receiving end, the consumer or application is responsible for reassembling these chunks in the correct order and format once all the data has been received. This process happens automatically for images, videos, and other relatively large data types.

So what Streams API offers is a way to instead of waiting for your full data to be available

handle data in real-time as they are received as chunks during the consumer stage and that is very useful and borderline essential when dealing with large amounts of data like the examples I would show in this article.
it also allows you to treat our data as a stream which is useful on the backend side when you want to send a specific type of chunks and in the frontend when using like workers to send large files through the network"

Revised Text: "What the Streams API offers is a way to handle data as it arrives, rather than waiting for the entire dataset to be available. Here are two key benefits:

Real-Time Data Handling: It allows you to process data in real-time as it is received in chunks. This capability is crucial when dealing with large amounts of data, such as the examples I will discuss in this article. (this article focuses on the first part)
Stream-Based Data Management: The Streams API enables you to treat data as a continuous stream. This is useful on the back end for sending data in specific chunks and on the front end for using web workers to upload large files efficiently.

Let's start by comparing the traditional method of receiving data using the Fetch API with the new Streams API approach.

Traditional Approach with Fetch API




fetch("url") .then((response) => {
// Note that there is a middle step before we receive the final data
// Let's see what we actually receive
console.log(response.body); return response.text(); }) .then((data) => { // Perform operations with the data
});

In this example, response.body is a ReadableStream object:



ReadableStream { locked: false, state: 'readable', supportsBYOB: true }

Here, we encounter the first component of the Streams API: ReadableStream. The ReadableStream constructor creates and returns a readable stream object, which allows us to handle streaming data more efficiently. We can use this constructor to manage data in chunks rather than waiting for the entire dataset to be available.



{ arrayBuffer(): Promise<ArrayBuffer>; blob(): Promise<Blob>; formData(): Promise<FormData>; json(): Promise<any>; text(): Promise<string>; }

We need to implement a function that handles the object to access data as it is sent in real time. This function should:
1 Receive the ReadableStream as a promise.

Wait for all chunks of data to be received.
Merge the chunks into the full dataset. Return the complete data as a promise.

Diving into ReadableStream



interface ReadableStream<R = any> {
  readonly locked: boolean;
  cancel(reason?: any): Promise<void>;
  getReader(options: { mode: "byob" }): ReadableStreamBYOBReader;
  getReader(): ReadableStreamDefaultReader<R>;
  getReader(options?: ReadableStreamGetReaderOptions): ReadableStreamReader<R>;
  pipeThrough<T>(
    transform: ReadableWritablePair<T, R>,
    options?: StreamPipeOptions
  ): ReadableStream<T>;
  pipeTo(
    destination: WritableStream<R>,
    options?: StreamPipeOptions
  ): Promise<void>;
  tee(): [ReadableStream<R>, ReadableStream<R>];
}



interface ReadableStreamDefaultReader<R = any>
  extends ReadableStreamGenericReader {
  read(): Promise<ReadableStreamReadResult<R>>;
  releaseLock(): void;
}

To work with the stream, we use getReader() which returns a ReadableStreamDefaultReader.

Here’s an example where we make a request to Lichess.org’s API for games in PGN format (think of it as text) for a certain user. The final result should be in text.



fetch("https://lichess.org/api/games/user/gg").then((response) => {
  console.log(response);
  const readablestream = response.body;
  console.log(readablestream);
  const reader = readablestream.getReader();
  console.log(reader);
});

Output:



ReadableStream { locked: false, state: 'readable', supportsBYOB: true } ReadableStreamDefaultReader { stream: ReadableStream { locked: true, state: 'readable', supportsBYOB: true }, readRequests: 0, close: Promise { <pending> } }

note you can't have multiple readers at the same time as the getReader() will throw an error if the ReadableStream.locked = true, so if u want to change the reader you have first to release the lock using ReadableStreamDefaultReader.releaseLock()



fetch("https://lichess.org/api/games/user/gg").then((response) => {
  const readablestream = response.body;
  console.log(readablestream);
  const reader = readablestream.getReader();
  console.log(reader);
  try {
    reader.releaseLock();
    const reader2 = readablestream.getReader(); 
// won't throw an error
    const reader3 = readablestream.getReader(); 
// will throw an error
  } catch (e) {
    console.error(e.message); 
// Invalid state: ReadableStream is locked
  }
});

now we use the read function inside the reader which has two variables

value: has the current chunk content in UintArray which we can convert to a string by converting each int to char and merge or simply using the TextDecoder().decode()



let string = result.push(
  value.reduce((p, c) => {
    return p + c.fromCharCode();
  }, "")
); // or
let string = new TextDecoder().decode(value); 
// both achieve the same thing converting Uint8Array to string

Full Code Example

Here’s a full example of handling the stream and merging chunks:



fetch("https://lichess.org/api/games/user/gg")
  .then((response) => {
    return new Promise((resolve, reject) => {
      const readablestream = response.body;
      const reader = readablestream.getReader();
      let result = [];
      reader.read().then(function handlechunks({ done, value }) {
        if (done) {
          resolve(result);
          return;
        }
        const pgn = new TextDecoder().decode(value);
        result.push(pgn);
        reader.read().then(handlechunks);
      });
    });
  })
  .then((result) => {
    console.log(result);
  });



// console.log(value)
Uint8Array(551) [
     91,  69, 118, 101, 110, 116,  32,  34,  82,  97, 116, 101,
    100,  32,  98, 108, 105, 116, 122,  32, 103,  97, 109, 101,
     34,  93,  10,  91,  83, 105, 116, 101,  32,  34, 104, 116,
    116, 112, 115,  58,  47,  47, 108, 105,  99, 104, 101, 115,
    115,  46, 111, 114, 103,  47,  90, 122,  78,  66,  90, 119,
    100,  71,  34,  93,  10,  91,  68,  97, 116, 101,  32,  34,
     50,  48,  50,  48,  46,  48,  49,  46,  49,  48,  34,  93,
     10,  91,  87, 104, 105, 116, 101,  32,  34,  86, 101, 101,
    118, 101, 101,  50,
    ... 451 more items
  ]
// console.log(new TextDecoder().decode(value))
[Event "Rated blitz game"]
[Site "https://lichess.org/ZzNBZwdG"]
[Date "2020.01.10"]
[White "Veevee222"]
[Black "gg"]
[Result "0-1"]
[UTCDate "2020.01.10"]
[UTCTime "20:21:02"]
[WhiteElo "1858"]
[BlackElo "1863"]
[WhiteRatingDiff "-6"]
[BlackRatingDiff "+35"]
[Variant "Standard"]
[TimeControl "180+0"]
[ECO "C00"]
[Termination "Normal"]



1. e4 e6 2. d4 d6 3. c4 Nf6 4. Nc3 c5 5. f4 cxd4 6. Qxd4 Nc6 7. Qd1 b6 8. g3 Bb7 9. Bg2 Rc8 10. Nf3 Be7 11. O-O O-O 12. b3 Nb4 13. Bb2 a5 14. Re1 Qc7 15. a3 Na6 16. Rc1 Nc5 17. Qd4 Nxb3 18. Qd1 Nxc1 19. e5 0-1

for example link

for example, full code go

Now, we can access the games' PGNs progressively as they are sent through the network. For example, if we are using the loaded games in a website UI, the user won't have to wait in front of a blank or loading screen until all the games are loaded. Instead, data can be displayed progressively, which is much better from a UX standpoint.
for example full code go here

MultiThreading In JS using Web Workers

Anas Mustafa — Wed, 14 Aug 2024 17:24:19 +0000

Web Worker: a way to run scripts in the background in different thread than the current main(Window)thread.

Web workers vs asynchronous using event_loop
Introduction to Web Workers
how to create a web worker
For example with a web worker
limitation of Web Workers
asynchronous operation in Web Workers

1. Web Workers vs Asynchronous Operations Using Event Loop

JavaScript typically handles asynchronous operations by placing tasks into corresponding queues (macro-task queue, micro-task queue), with the event loop continuously checking these queues and pushing tasks into the call stack when they're ready to be executed. This approach ensures non-blocking execution but still runs everything on a single thread.

Web Workers, on the other hand, allow scripts to run in a completely separate thread with its own call stack, asynchronous queues, and event loop. This separation prevents the main thread from being blocked by heavy computations or long-running tasks, as the worker operates independently.

2. Introduction to Web Workers

Web workers execute scripts in a different context than the main window context, enabling parallelism in web applications. The Web Worker API provides several types of workers:

Dedicated Workers: Utilized by a single script, these are ideal for offloading tasks from the main thread.
Shared Workers: Accessible by multiple scripts running in different contexts (e.g., different windows or iframes).
Service Workers: Operate as a proxy server between web applications, the browser, and the network, providing functionalities like offline support and caching.

This article focuses on dedicated workers, which are the most straightforward to implement and commonly used.

3. How to Create a Web Worker

To create a web worker, you can use the following key methods:

new Worker(): The constructor to create a new worker.
postMessage(): Sends messages from the main thread to the worker or vice versa.
onmessage: A callback function set to handle messages received by the worker.
terminate(): Stops the worker immediately.

4. Simple Example

Let’s create a worker to fetch data from an API, specifically dog images from the Dog CEO API.

4.1 Worker Code

Here’s the implementation of the worker script. Notice that inside the worker, self is used to refer to the global context:



if (window.Worker) {
    const worker = new Worker("/src/worker.js");
        worker.postMessage({ 
            operation: "get_dog_imgs",
            url: "https://dog.ceo/api/breeds/image/random", 
            count: 5   //number of photos
        });
        worker.onmessage = (e) => {
        console.log(e.data);
        if (e && e.data) {
            setdata((old) => [...old, e.data]); // update react state
            showCallStack(); // function to show the callstack 
        }
    };
    worker.onerror = (e) => {
        console.log(e);
    };
}

In this code, the worker listens for messages (onmessage) and fetches data from the given URL multiple times as specified by the count.

Here’s what the call stack looks like inside the worker:

4.2 Client Code

The main thread uses the worker like this:



self.onmessage = (event) => {
    const data = event.data;
    if (data && data.url && data.count) {
        fetchFromUrls(data.url, data.count);
    }
}
// fetch single data 
const fetchdata = async (url) => {
    const res = await self.fetch(url);
    return await res.json();
};

const fetchFromUrls = async (url, count) => {
    showCallStack(); // showing the callstack of the worker 
    for (const i of new Array(count).fill(0)) {
        let data = await fetchdata(url);
        if (data && data.message) {
            self.postMessage({ type: "img", data: data.message });
        }
    }
};

This code demonstrates how to send a message to the worker and receive the fetched data in the main thread.

for full code go to code

5. Limitations of Web Workers

While web workers run in a separate thread from the main window thread, they come with certain limitations:

No Access to DOM: Workers cannot directly manipulate the DOM. Communication with the main thread is necessary to update the UI.
Resource Consumption: Overusing web workers can lead to high memory usage, as each worker requires additional resources to operate independently.

IndexedDb A bigger LocalStorage

Anas Mustafa — Fri, 09 Aug 2024 20:29:28 +0000

what is indexed let's look at the MDN definition of indexedDB: IndexedDB is a low-level API for client-side storage of significant amounts of structured data, including files/blobs.
so essentially we can use it when the local storage is too small for your needs.

note: IndexedDB is a mix between SQL and NoSQL databases as its a Transactional db like SQL databases but it also a js object oriented db like NOSQL databases

table

creating the database
creating the store
creating transaction
doing crud operation



IDBFactory{
    open(name, version?: number): // opening a database returns IDBOpenDBRequest
    deleteDatabase(name: string): 
    cmp(first: any, second: any): 
    databases(): 
}
IDBOpenDBRequest{
    onblocked:
    onupgradeneeded:
    addEventListener:
    removeEventListener:
    onerror:
    onsuccess:
    readonly readyState: 
    readonly result: 
    readonly source: 
    readonly transaction:
}
IDBDatabase{
    onabort: 
    onclose: 
    onerror:
    onversionchange:
    transaction:
    addEventListener:
    removeEventListener:
    deleteObjectStore:
    close:
    createObjectStore:
    readonly version:
}
IDBTransaction{
    readonly db: 
    readonly durability: 
    readonly error: 
    readonly mode: 
    readonly objectStoreNames: 
    onabort: 
    oncomplete: 
    onerror: 
    abort(): 
    commit(): 
    objectStore:
    addEventListener:
    removeEventListener:
}

simple diagram to show how to open the database and do simple crud operations as you can see all operations follow the same pattern doing action and then listening to the INDRequst for success or other response

1. Open a database and creating store

The open operation doesn't open the database right away or start a transaction right away it returns an object of type IDBOpenDBRequest in success and throws an error incase of an error.

most operation work the same way the return some type of IDBRequest for which u have to listen to success or error.



const request = window.indexedDB.open("databasename", 1);
request.onupgradeneeded = (event: IDBVersionChangeEvent) => {
    const db = request.result;
    if (!db.objectStoreNames.contains(storeName)) {
        // creating store if it doesnot exist
        db.createObjectStore(storeName);
    }
};
request.onsuccess = (e) => {
    console.log(e);  
};
request.onerror = (e) => {
    console.error(e);
}

2. getting access to the database and store



const db = request.result; // the request from the indexedDB.open()
const transaction = db.transaction(param.storename, 'readwrite');
const store = transaction.objectStore(param.storename);

3. doing crud operations

3.1 adding data



let request = store.add(data, key)
if (request) {
request.onsuccess = () => {
 // success
};
request.onerror = (e) => {
    throw new Error(e);
};

3.2 deleting data



const request = store.delete(param.data.key);
request.onsuccess = () => {
 // success
};
request.onerror = (e) => {
    throw new Error(e);
};

3.3 modifying data



const request = store.put(data, key);
request.onsuccess = () => {
 // success
};
request.onerror = (e) => {
    throw new Error(e);
};
);

3.4 getting specific collection data

indexedDb offer a way to have access to data at the same time the database is searching through the database store.openCursor

3.4.1 fetching all store data



let data = [];
store.openCursor().onsuccess = (event) => {
try {
const cursor = event.target.result;
if (cursor) {
data.push({ value: cursor.value, key: cursor.key });
cursor.continue();
} else {
console.log('finished');
}
} catch (e) {
 throw new Error(e);
}
};

you can convert all operation to asyncronous function for easy use
converting adding data to return a promise



const addData = async (db, storename, data, key) => {
    const transaction = db.transaction(param.storename, 'readwrite');
    const store = transaction.objectStore(param.storename);
    let request = store.add(data, key)
    if (request) {
    request.onsuccess = () => {
     // success
    };
    request.onerror = (e) => {
        throw new Error(e);
    };
}
await addData(db, "storename" , {/*somedata*/}, "key").

full code converted to async funciton at github

Forem: Anas Mustafa

From PreReact to React and Next.js A Journey Through Web Rendering and Performance Optimization

A Brief History: Before React.js

Now Enter React.js

Reconciliation:

Now Enter Next.js

React Performance Optimization Techniques Part 1

1. list virtualization

2. lazy loading images

Why Use Lazy Loading?

Basic Example: Lazy Loading with loading="lazy"

Advanced Example: Lazy Loading with Intersection Observer

Conclusion

3. memoization

1. useMemo

2. Memo

Behavior without React.memo:

Introducing React.memo:

Conclusion:

3. useCallback

Why is this useful?

Example: Using useCallback to Prevent Unnecessary Re-renders

Before Using useCallback

Solution: Using useCallback

Conclusion

Why the Streams API is a Game-Changer for Web Developers

Traditional Approach with Fetch API

MultiThreading In JS using Web Workers

1. Web Workers vs Asynchronous Operations Using Event Loop

2. Introduction to Web Workers

3. How to Create a Web Worker

4. Simple Example

4.1 Worker Code

4.2 Client Code

5. Limitations of Web Workers

IndexedDb A bigger LocalStorage

table

1. Open a database and creating store

2. getting access to the database and store

3. doing crud operations

3.1 adding data

3.2 deleting data

3.3 modifying data

3.4 getting specific collection data

3.4.1 fetching all store data

Basic Example: Lazy Loading with `loading="lazy"`

Behavior without `React.memo`:

Introducing `React.memo`:

Example: Using `useCallback` to Prevent Unnecessary Re-renders

Before Using `useCallback`

Solution: Using `useCallback`