Forem: RAJIB DAS

The Elements of Browsers Rendering

RAJIB DAS — Wed, 04 Feb 2026 13:09:13 +0000

What web browsers do when a user requests a page is quite a remarkable journey. My goodness, the process behind the curtains reflects such a diligent effort by the folks who work on browsers. So far, I find it very interesting to navigate through the steps that are taken to draw pixels on the screen. I’ll admit it, this is a surprisingly deep and interesting area. As developers, we sustained the focus quite a bit on performance, especially when building things on scale.

If we want to have a strong hold on the rendering performance metrics of browsers and on improving bottlenecks, I feel we’d better keep on detouring on this route to better off ourselves with the right combination of knowledge, experience, and tooling. Otherwise, taking a long time to load a fully interactive page as well as responding to user interactions can ruin a good user experience. After all, the only thing that matters, and we’ll ever need in software, is the good user experience.

So what I want to do today is put down some of the insights I’ve learned by writing code, reading articles and watching various conference talks about the absolutely critical, need-to-know bits of page rendering procedures in the web-space. Let’s put in the work.

It all starts with hitting a request in the address bar. That submission will initiate a DNS lookup if the website is requested for the first time, as some caching might appear to speed things up. DNS lookup returns an actual IP address, which is the location of the server where the requested file is stored. The browser has the IP now. It now establishes a connection to that IP so that they can communicate effectively, which is known as TCP Handshake. But effective isn’t the only goal. It needs to be secured in that no 3rd party entity can read the data that is being exchanged by them. To ensure that another handshake is done, called TLS Negotiation.

All the back and forth messages are done via HTTP protocol. Once the connection part is done, the browser then sends a get request for the HTML file, and the server starts to send the raw data in batches, as the server has the ability to send the response in chunks, especially for larger responses since that’s the core part of web infrastructure.

I like the analogy that I found in the MDN docs. It states like this: If we imagine that the internet is a road. At one end of the road is the client, which is like our house. On the other end of the road is the server, which is like a shop we want to buy something from.

Then the internet connection is basically like the street between our house and the shop. DNS is like looking up the address of the shop before we visit it. TCP is like a car or a bike (or however else we might travel along the road), and HTTP is like the language we use to order our goods.

Once the handshake and connection are done, the browser starts to assemble them into something meaningful that the user wants to see.

To achieve that, it has a couple of pipelines to go through to convert the bytes to visual pixels on the screen.

As soon as the browser gets the first chunk of raw bytes, it needs to build a structure they can work with. And for that, it converts the raw bytes to tokens, which are like vocabularies of a language. From tokens, it generates nodes, which contain all the information necessary about a certain HTML element, and all the nodes are modeled into a tree data structure, which functions as a relationship model between things. This internal representation of the HTML file is known as the DOM tree. It can be manipulated by various DOM methods and properties in JavaScript.

While parsing the HTML, the parser may find stylesheets, which can’t modify the DOM, so building of the DOM tree process continues along with downloading and parsing CSS to build the CSSOM tree. Parsing the CSS involves resolving conflicting CSS declarations, as CSS can come from different sources, i.e., user agent, author declarations etc.

The browser needs to build both trees independently because the next step, which is render tree creation, can't be done unless DOM and CSSOM are ready. Had it done only the DOM tree, then we’d have experienced an un-styled page for a moment, and after some time proper rearrangement will get placed because of styling, which would feel broken.

Speaking of external resources such as images, stylesheets, scripts, and fonts, optimization happens alongside parsing HTML through the preload scanner, which starts downloading the CSS, font, and script files that are high priority. The browser has internal rules of which files get prioritized but we can also control this behavior by tag.

<link rel="preload" href="very_important.js" as="script">

This optimization was invented because back in the old days when a script tag was found, then that would pause the HTML parsing because JS can manipulate the DOM. Instead, that script was first fetched, parsed, and executed before starting to resume the parsing. This way would delay the discovery of other files and bring waterfalls. Like this:

To prevent this waterfall, resources are downloaded in parallel so that when the HTML parser finds resources, those might already be in flight or have been downloaded. like this:

JS can also manipulate styles. So before JS execution, all the CSS files have to be downloaded and parsed and the CSSOM must be ready.

For instance, if we place the script tag in the head and before that script we put a link tag with a stylesheet, then when the HTML parser encounters the script, it stops parsing, but at the same time, JS also can’t be executed if CSSOM is not ready. As we can see, the consequences of delaying building the CSSOM and code structure can drag down both the JS and HTML parsing. That’s why the preload scanner’s main goal is to download the CSS files as quickly as possible so that CSSOM can be available in quick times.

CSS needs to be downloaded and parsed completely before JS can be parsed and executed. Even though browsers have preload scanners, we should place the script tag at the very end and styles at the top for that reason.

But nowadays we have better alternatives. If we place the script in the head and don’t want to pause the HTML parsing, we can mark the defer attribute to the script tag, and that will fetch the script in the background and start execution after the HTML has been fully parsed.

Coming back to the pipelines, since the DOM and CSSOM are ready, the browser starts to traverse the DOM tree, and for each node, it makes sure it has all the information for that element, plus it calculates the computed values from the CSSOM tree, figures out which styles apply to which elements, and forms a render tree. This tree excludes invisible elements like the head tag and its descendants and CSS declaration with display: none.

Now that the browser has the render tree in place nicely, it starts to traverse the render tree to calculate what dimensions each node should have and exactly where on the screen the node will sit based on couple of factors. Some of these are: device viewport size, CSS box model, CSS layout modes (flex layout mode, grid layout, positioned layout, flow layout etc.). This process is referred to as layout calculation, if this is running for the first time, but on subsequent reruns it’s called reflow.

So far the browser has the render tree consisting of nodes and has done all the calculations of where they need to be painted. Coming to the actual drawing work, this is where the browser figures out which colors to assign to every visual element in the render tree (“rasterization”) and filling it in.

To ensure repainting can be done faster, drawing the page split up into distinct layers, sometimes depending on the styles we are using, so that it can re-paint only the part that needs to be changed, and after repainting, the browser then offloads layers to the compositing phase so that it can merge all the layers together into one final image. Similar to design mockups in Figma and others. With this method, the painting process can reuse the work it has done in the previous paint and only change what hadn’t been done previously.

Styles calculation, layout, and paint phases happen in the main thread in the CPU. The Compositing phase happens on a different thread, which is inside the GPU, where the expensive calculations are done much faster than on the CPU.

When the browser breaks up the paint process into layers, after the painting process, those layers consist of painted pixels (A.K.A. textures or flat images). Earlier I mentioned depending on the styles browsers create separate layers, and those are transform, opacity, will-change, filters, and a couple more. And if we animate these properties, they don’t trigger layout or paint phases. Instead, they can be animated with compositing alone and a little bit of style re-calculation. Layout and paint phases won't rerun in this case, which reduces the work greatly. Otherwise we would have done those expensive measurements many times a second. Leveraging this leads to a smoother motion.

Make use of any of these properties treats our element like a single image on a separate layer and then does the texture-based transformation, which is essentially to move, scale, rotate or fade the already painted pixels and then merge that layer with other layers to form a single bitmap, which can be shown on the UI. Since these happen on the GPU, it makes the animation very slick and performant. This is known as hardware acceleration.

Sometimes it brings one problem though: when the CPU hands it to the GPU to animate the transform property, there's a slight glitch that can appear in text when animating because of a slight difference in the method they use to render things. To remove that, we can use the following CSS:

.btn { will-change: transform; }

This now will be managed by the GPU all the time, with no handing off. You can try this exercise by yourself. Try creating a button, and then on hover translate it a little bit up or down. You will notice that the text shifts slightly or the characters’ thickness grows or shrinks a bit.

Compositing can also be very useful with smooth scrolling. For example, in the early days of the web, when user scrolled, the entire page had to be re-painted again which felt laggy and kind of redundant.

So to skip the paint process, the browser now transforms the page's content up or down when the user scrolls. So by sliding up and down, it speeds up the frame rate in lightning quick time, as it doesn’t have to do many calculations because that has already been done by the paint process. It just stacks up the layers in correct orders, transform them up or down and combine them correctly into a single image.

Important to remember here is this layering work is done by the GPU instead of the CPU, which improves performance, but it does take up memory, so that’s the tradeoff we need to be aware of.

Which steps will re-run in the pixel pipeline depends on CSS properties. If an element width is changed from 200px to 300px on hover, then that will trigger the layout phase since an item growing might mean that its siblings move to fill the space. And then the re-paint and compositing. That’s the reason it’s best to avoid changing layout properties like width, height, margin etc., especially when animating, because that’s how we can skip a bunch of operations. Libraries like framer motion achieve animating layout properties with various techniques like FLIP.

But elements that have been taken out of the normal flow (i.e., absolute), changing width or height don’t affect the other elements. So cases like this, layout calculation, repaint usually happen much faster.

A quick plug: all the pipeline work that I mentioned (render tree construction, layout, painting, and compositing) is constrained with a tight time of ~16ms to make the UI motion feel fluid and believable. And the steps are blocking and sequential, as we’ve witnessed, done by one thread, which is the main thread. However main thread must also perform other tasks, such as responding to user input and executing JavaScript to keep the UI responsive also. And it is considered a bad and sluggish experience if a response to the user interactions and rendering steps both take greater than ~50ms.

To maintain optimal performance, it is also important to make sure JS execution doesn’t take that long.

Like I said earlier, this stuff is really deep. There are obviously many more nuances and intricacies that you can get into at each steps. I'll attach some helpful resources for you to dig even deeper. Not sure if I did a decent job of explaining things. Let me know how that turns out for you. I find it quite hard to keep this all straight in my head. But understanding this helps developers to build a pleasurable experience for the end-users.

Hopefully this writeup helped to add some light on your understanding and you are eager to learn more about it. Thank you so much for the ride.
You can connect with me on LinkedIn. There, I share programming related things just like this one as I learn them.

Resources:

P.S. If you wish to see how many layers a webpage has then browser dev-tool has a "layer tab" in which we can visualize them.

Making Sense of Bipartite Graphs

RAJIB DAS — Sun, 01 Feb 2026 12:56:15 +0000

Developing strength in the area of graph is a great outlet to sharpen your programming craft. It also has ripple effect. You wander with queue, stack, priority queue and what not, while dealing with graph.

To get a glimpse of it, in today’s issue, I’d like to communicate briefly, the idea of Bipartite Graph and its implementation in a very gentle manner. Let's go.

The Whole idea with graph is, we make connections between things, which forms a network along its perimeter. A connection sets a bond between two nodes. And If it is possible for two distinct colors to be exhausted on each edge, then we wind up calling it a Bipartite. You’ve gotta run out of two colors.

Since the structure of a graph can be as broad as Ocean and simultaneously it can be as high as mountains, we can either traverse broad by exploiting neighbor nodes before descendants or can go deep by striking descendants first.

These two are the most common techniques to lean into when information is organized like this. First one is BFS (Breadth First Search) and Latter one is DFS (Depth First Search).

Let’s lining out what steps the BFS Algorithm takes internally for Bipartite check:

→ entering the function with a starting node, first thing it does is enqueue the starting node into the queue data structure

→ gives the starting node a color (0 | 1, model as 2 distinct colors) in the colors[] array

→ runs a loop until the queue is empty and on each iteration:
1) dequeues a node
2) fires yet another loop to see all of its neighbors and look for 3 things for each neighbors: If the neighbor node is not yet colored, it gives a color opposed to dequeued node’s color and enqueue that afterwards,
else if the neighbor is already colored and its color got blended in with the dequeued node then it is not a bipartite graph, it then terminates the function straight away but if it is having the opposite color then continue.

→ Finally, the queue becomes empty here, which means, it didn’t fall into the identical color consequences, sure thing, we can safely say the given graph conforms the bipartite rules.

Here’s the BFS implementation in TypeScript:

enum COLORS {
  COLORED_RED = 0,
  COLORED_GREEN = 1,
  NOT_COLORED = -1,
}


const checkBipartiteBFS = function (
  startingNode: number,
  adj: number[][],
  colors: COLORS[]
): boolean {

  // define a queue and give starting node a color and enqueue it
  const queue: number[] = [];
  colors[startingNode] = 0;
  queue.push(startingNode);

  // run a loop until queue becomes empty
  while (queue.length !== 0) {
    // dequeues a node
    const node = queue.shift() as number;

    // look for its neighbour nodes and do those checking stuffs and all
    for (let j = 0; j < adj[node].length; j++) {
      const neighbourNode = adj[node][j];

      // both the neighbour and dequeued node are having same color, not a bipartite
      if (colors[neighbourNode] === colors[node]) {
        return false;
      }

      //  neighbour node is not colored,so color and enqueue it in turn         
      if (colors[neighbourNode] === -1) {
        colors[neighbourNode] = (colors[node] + 1) % 2; // 0 becomes 1 and 1 becomes 0
        queue.push(neighbourNode);
      }
    }
  } 

  // queue becomes empty here, it is a bipartite graph surely
  return true;
};

A quick Primer on Recursion —

since DFS is recursive by nature, thereby, we don’t push a node into the queue every time we discover an un-colored node. Instead we invoke the function again with the un-colored node. That’s it. That’s the only major difference to observe.

we are repeating the same thing on each iteration if we look closely on BFS. So why not calling the function itself from within itself but with different node, otherwise the pitfall of recursion pops up, business as usual (shoutout to stack overflow).

With that in mind, let’s look at the steps of DFS Algorithm for Bipartite:

→ entering the function with a node and a color, it starts by giving the node that color in the colors[] array

→ fires a loop to see all of its neighbors and look for the followings:
If the neighbor node is not yet colored, it calls the DFS function again with the neighbor node and a color opposed to dequeued node’s color. If the call comes back with a “false” value then no need to iterate further, return “false” here as well. Because rules broken by one node in the graph is enough to call it not a bipartite.
else if the neighbor is already colored and its color got blended in with the dequeued node then it is not a bipartite graph, it then terminates the function straight away with return “false” but if it is having the opposite color then continues.

→ Lastly, the queue becomes empty here, this node didn’t fall into the identical color consequences. So it returns “true” here, which simply means, this node is not the one that break the bipartiteness and exit this execution to go back to where the function came from.

Here’s the DFS implementation in TypeScript:

enum COLORS {
  COLORED_RED = 0,
  COLORED_GREEN = 1,
  NOT_COLORED = -1,
}


const checkBipartiteDFS = function (
  node: number,
  color: 0 | 1,
  colors: COLORS[],
  adjList: number[][]
) {
  // give that node a color 
  colors[node] = color;

  // look for its neighbours and do the checking and call the function recursively if needed
  for (const neighbourNode of adjList[node]) {
    // both having the same color, return false right away
    if (colors[neighbourNode] === colors[node]) return false;

    // neighbour node is not yet been colored, so call the function again with the opposite color
    if (
      colors[neighbourNode] === -1 &&
      !checkBipartiteDFS(neighbourNode, color === 0 ? 1 : 0, colors, adjList)
    ) {
      return false;
    }
  }

  // the iteration has been done and this node did not break the bipertiteness, so we return true
  return true;
};

There you have it. I hope, it was helpful. Thanks so much for reading.

You can connect with me on LinkedIn. There, I share programming related things just like this one as I learn them.

Reactive Effects that preserves component's Cohesiveness

RAJIB DAS — Sat, 01 Nov 2025 08:25:40 +0000

It’s not fairly new that when we have bunch of complex data which lives in a database then mainly the essential job of a web application is to act as an interface (a window) to those data that let users read and manipulate. To perform these user centric action we usually need to implement filter, sort, search, pagination etc.

When working on the implementation, we often need to handle quirky behaviors, for instance: to keep them sync with each other. If a user is on page 3 and then start typing on search input or change the filter, the pagination should adapt, right?

I can hear you saying, this edge case isn’t a big deal after all the solution is remarkably straightforward. But that’s not the point here. I want to share some perspective change that I’ve had working with it.

That said, in terms of solution, we can reset the page state on Search Component. Like when setting the new search input value we’ll also set the page state to 0. Like this:

// Using a package for managing type safe url query
import { useQueryState, useURLQueryStates, parseAsString, parseAsInt } from "nuqs";

import { SearchInput } from "@/components/search-input";

export default function RegistrationRequestsSearchInput ({ placeholder }) {
  // use "nuqs" hook to manage the search input state in the url
  const [search, setSearch] = useQueryState(
    "search",
    parseAsString.withDefault(""),
    { shallow: false, clearOnDefault: true }
  );

  // only needed to call this hook to reset the page state 
  const [pagination, setPagination] = useURLQueryStates(
    {
      page: parseAsInt.withDefault(1),
      size: parseAsInt.withDefault(10)
    },
    {
     shallow: false,
    }
  );

  function handleSearch(value){
      setSearch(value);
      // reset the page state to 1
      setPagination({ ...pagination, page: 1});
  }

  return (
    <SearchInput
      value={search}
      onChange={handleSearch}
      placeholder={placeholder}
    />
  );
};

Sure it’s a viable solution and for a long time I used to solve this way. But as my experience with component driven approach becoming more mature I start to realize why it’s better to avoid this pattern.

Let’s take a moment to analyze this a little bit and see if we can extract a lesson or two from here.

Setting a new page state leans heavily into Pagination component - that’s why it exist in the first place. Search Component is interfering with it by setting a new value technically works alright it becomes hard to keep track of which code is doing page state manipulations with time and code move slightly towards in the direction of spaghetti.

Think about the case when we have to do the same inside Filter Component if resetting page state also necessary whenever filter state changes. Wouldn’t it be nice to co-locate setting the page state stuff entirely on the Pagination Component?

You might be thinking it’s a global state as we set it in a url but that “global” here is in the sense of, we need it in a multiple different corners in our app but we don’t necessarily need to set it from those different components at least in this case I think so. we can reserve the setter function for the Pagination component only.

So from Pagination component, how do we know when we need to reset state. well use-effect hook could be the great use case for this.

I applied this reactive solution quite often now a days when building apps in my current job.

here’s the new lens in action:

export default function RegistrationRequestsPagination() {
  // use "nuqs" hook to manage the pagination state in the url
  const [pagination, setPagination] = useURLQueryStates(
    {
      page: parseAsInt.withDefault(1),
      size: parseAsInt.withDefault(10)
    },
    {
     shallow: false,
    }
  );

  const [search, setSearch] = useQueryState(
    "search",
    parseAsString.withDefault(""),
    { shallow: false, clearOnDefault: true }
  );

  const prevSearch = useRef(search);

  useEffect(() => {
      // we can also listen for other changes i.e. filter. The idea is we can add 
      // more reactive state in here whenever we need to reset the page state.
    if (search === prevSearch.current) return;
    prevSearch.current = search;

    setPagination({ ...pagination, page: 1});
  }, [search, pagination, setPagination]);

  return (
    <Pagination
      pagination={pagination}
      onPagination={setPagination}
      paginatedMetadata={paginatedRegistrationsMetadata}
    />
  );
};

So what do you think about this? Is this actually outshine the previous one? Essentially this method of Reactive Effects preserves component's Encapsulation.

We are lean into the idea of cohesive approach (the degree to which elements of a module belong together) and reactive approach something radical that react brought with it when they introduced Component for writing application.

Reactive in the sense that here, we describe the reset page state with an effect. we are saying when the search input is different then backtrack the page state to 0. Describing it once and for all. we can listen the filter state change also if needed.

and cohesion in the sense, Pagination component is now the ultimate contract holder for setting page state and that’s what makes sense in this case I guess.

In the example above, Search Component and Pagination Component is like self independent thing, they only think about them, they act like they do not have the contract of changing other components things. This cohesiveness, this single source of truth makes the application more predictable and more organized.

This is One of the best things about Component pattern, that they encourage this sort of good habits.

Thank you so much for taking the time to read it. Feel free to drop your thoughts about this because I think it's a bit subjective.

The “Why” Behind React Suspense: Quest for the Original Vision

RAJIB DAS — Fri, 03 Oct 2025 14:59:30 +0000

Discover the why something was originally thought of makes us appreciate the tool + the way we use the tool as well as promote us to a couple of levels of we know what we are doing. It’s one of those inside job feeling.

I continuously invest in this quest, in this lightbulb moment when it comes to learning. Feeding mind with this gives us a right conceptual model of something. That way we can make and move things faster with accuracy. It's no brainer why right mental models are the ideal interface for holding essence of something.

Recently I’ve been fortunate enough to meet one such moment. It was really an eye-opening realization for me. So this is my attempt to write some words of my understanding. Optimistic you’ll find some values through this. It’s about React Suspense Component. Let’s dive in.

A very common theme we notice in applications is that they fetches and manipulate data that lives in a database. And there's a whole category of challenges of this and one of them is Data Fetching. How do we fetch Data or more preciously how do we fetch data with component driven framework like react. I deliberately bring component here because that's how most of us build products at least on the Frontend.

const res = await fetch("https://www.yourapp.com/users");
const data = await res.json();

Let’s talk about couple of cases that need to take care of this two lines of code. First noticeable case, between the await and fetch calls for getting data, there’s definitely going to be some delay. So need to handle the loading period. Other case would be what happens when calling doesn’t go well - maybe it’s a 404 or 500. Showing Loading & Showing Error are things we need to be aware of.

In react, the way we can do that is with use hook. Although It’s a versatile tool but let’s only focus on one thing here, data fetching.

function App() {
  return (
    <div className="app">
      <ErrorBoundary fallback={<div>Something went wrong</div>}>
        <Suspense fallback={<InvestmentSeekingLoading />}>
          <InvestmentSeekingBox />
        </Suspense>
       </ErrorBoundary>
    </div>
  )
}

const investmentSeekingPromise = getInvestmentSeeking()

function InvestmentSeekingBox() {
  const data = use(investmentSeekingPromise);

  return <div>{/* Stuff using `data` */}</div>;
}

So as we can see from the code, It takes a promise as a parameter. If we call this with a promise then component will stop it’s execution right off the bat and bubble up to a closest Suspense component and showed us the given loading spinners. And when the promise is resolved then react will unmount the loading fallback and start executing the component again but since the promise has been resolved so we don’t have to fall into the halting process again (this is also the reason we're not allowed to create the promise inside components otherwise every time we'll fall into the loading consequences again and again) instead it returns us the actual data this time and as a result showing it on the UI. but If the promise rejects then react will not try to render the component again instead it bubble up even more to find out an Error-Boundary and swap the loading with this.

Two steps does the job pretty cleanly: 1) wrap the component with Suspense and 2) prompt react to stop processing the rendering until the promise has resolved by throwing promise.

use hook throws a pending promise that we give. That's how component is able to communicate that it is not ready to render yet. Internally there's some mechanism inside React to catch that promise and suspend the render unless the promise resolves to render the components as this time promise is not pending so we got the actual data to work with.

After some time digesting this pattern, A question comes into my mind, why we need Suspense and Error-Boundary when dealing with loading and error. Can’t we handle these inside the component itself?

I mean "the thinking of component model" is, it’s A package, it should own it’s markup, it should own it’s styling, it should own it’s logic and it also should own it’s data fetching. No other components on the other side of the app should be able to meddling with this component. But with Suspense and Error-Boundary it’s not happening (sure data request is happens inside components but not loading and errors). If use hook gives us loading and error variable then it would be completely owned it’s own things component and satisfied the component definition. React did not design the API this way because there’s actually a real problem with this which is known as Layout Shift.

The way I was introduced to this from a tweet by andrew clark.

Spinners all around. The fact that component has to be highly cohesive, it has to contains and receive everything they need to render the UI is lead us to this problem of things shifted around on the initial load which not offers a good experience for the user. Each Component resolves data at different time, and so the problem arises.

Here we can see, each components for themselves, doing their own thing:

function InvestmentSeekingBox() {
  const { isLoading, data, error } = useQuery({
    queryKey: ["InvestmentSeeking"],
    queryFn: getInvestmentSeeking,
  });


  if (isLoading) {
    return <Spinner />;
  }

  return <div>{/* Stuff using `data` */}</div>;
}

function InvestmentVerificationBox() {
  const { isLoading, data, error } = useQuery({
    queryKey: ["InvestmentVerification"],
    queryFn: getInvestmentVerification,
  });

  if (isLoading) {
    return <Spinner />;
  }

  return <div>{/* Stuff using `data` */}</div>;
}

function Dashboard() {
  return (
    <>
      <InvestmentSeekingBox />
      <InvestmentVerificationBox />
    </>
  );
}

Imagine 5 or 6 components on this Dashboard then components pushing other components will be visible clearly each time they finished their loading because different component finished their loading at different point in time because of asynchronous nature, like we saw in the tweet.

One way to avoid this experience is to hoist the data fetching to a common ancestor component and pass the data at once when all of the fetching is completed.

Here, Dashboard is in charge for all of the components to audit the Spinners mess:

function Dashboard() {
  const { isLoading: isInvestmentSeekingLoading, data: investmentSeekingData } =
  useQuery({
    queryKey: ["InvestmentSeeking"],
    queryFn: getInvestmentSeeking,
  });

  const { isLoading: isInvestmentVerificationLoading, data: investmentVerificationData }
  = useQuery({
    queryKey: ["InvestmentVerification"],
    queryFn: getInvestmentVerification,
  });

  // If *either* request is still pending, we'll show a spinner:
  if (isInvestmentSeekingLoading || isInvestmentVerificationLoading) {
    return <Spinner />
  }

  return (
    <div>
      <InvestmentSeekingBox data={investmentSeekingData} />
      <InvestmentVerificationBox data={investmentVerificationData} />
    </div>
  )
}

But this solution doesn’t go well with component mentality because the actual component that work with the data can not completely owned their data fetching logic. We'll lose that ergonomic of encapsulation here. Also as the data fetching requests increases, component would be bloated.

So in the first case when every components for themselves, on plus side, we get a great DX but on minus side elements were not being gentle.

Talk about second case, it's the opposite. We control the components of how they behave but components can not own their data requests.

Suspense offers the best of both worlds, an ideal sweet spot with an addition of much more declarative-ish. Now components can own their data requests and also we can control how they show up on initial load by wrapping them with Suspense Boundary, similar to “hoisting fetching up” strategy. Now the only thing is to decide which components are wrap around which Suspense Component and part of the same group so that layout shifting don’t happen. Some Careful thinking needs on this depending on the application.

So Loading and Error state is attached with Suspense, outside of individual components because of the strict isolation of components make the whole space of UI a disaster. With Suspense we still retains the isolation as major thing the data request is still rests with the components but without that baffling experience.

I hope I was able to convey my understanding about why suspense was originally created.

Warm thanks to Joshua Comeau, who taught me this eye-opening realization about Suspense original Vision. This is my reflection note of that WHY.

𝐅𝐫𝐚𝐦𝐢𝐧𝐠 𝐒𝐭𝐚𝐭𝐞 𝐃𝐞𝐬𝐢𝐠𝐧

RAJIB DAS — Fri, 19 Jan 2024 03:43:41 +0000

State let component remember information and we need it when a certain user action needs to change data from one value to other value.

When Designing state in React Apps I follow a couple of guidelines that might be helpful for you:

1) 𝐎𝐮𝐭𝐥𝐢𝐧𝐞 𝐔𝐬𝐞𝐫𝐬 𝐁𝐞𝐡𝐚𝐯𝐢𝐨𝐫𝐬 𝐚𝐧𝐝 𝐜𝐨𝐧𝐬𝐞𝐪𝐮𝐞𝐧𝐜𝐞𝐬

The first step is to write all the steps users will do and what are the results they will see by using that component. This will force us to think about deeply what our component’s purpose actually is.

So we observed what are the commands that can be given by users as they interact with that component on the screen and what are the responses they got.

2) 𝐈𝐦𝐦𝐞𝐫𝐬𝐞 𝐲𝐨𝐮𝐫𝐬𝐞𝐥𝐟 𝐢𝐧 𝐨𝐧𝐥𝐲 𝐜𝐡𝐚𝐧𝐠𝐞𝐬

We need to set a specific intention here and don’t let ourselves be distracted by what is static in that component.

Our only awareness here should be what is changing on the screen and remove static parts from our mind. This leads us to narrow down our focus to one thing only and simplify things.

Alright, that's for state design. Time for think of a few strategies of where to place a state: Ask Yourself,

⇒ which other components need that state? If the answer is 0, then place that state only in that component and we are done.

⇒ Does that state needed by many different components such as - children, sibling, parent - then it’s a global state.

𝑻𝒉𝒂𝒏𝒌 𝒚𝒐𝒖 𝒇𝒐𝒓 𝒓𝒆𝒂𝒅𝒊𝒏𝒈 📖. 𝑰 𝒉𝒐𝒑𝒆 𝒚𝒐𝒖 𝒉𝒂𝒗𝒆 𝒈𝒐𝒕 𝒔𝒐𝒎𝒆 𝒎𝒆𝒂𝒏𝒊𝒏𝒈𝒇𝒖𝒍 𝒊𝒏𝒔𝒊𝒈𝒉𝒕𝒔 𝒂𝒃𝒐𝒖𝒕 𝒔𝒕𝒂𝒕𝒆 𝒎𝒂𝒏𝒂𝒈𝒆𝒎𝒆𝒏𝒕.