DEV Community: Mohan Sebastian

SSR and prefetching - use cache usage in Nextjs

Mohan Sebastian — Thu, 25 Jun 2026 21:46:38 +0000

Before starting this topic, let me clarify something: I’m not going to explain what pre-fetching or SSR is, or try to teach different ways of implementing them in Next.js.

I just want to share my experience with these features: why we decided to use them, what goals led us to this decision, what downsides they caused for us, and what benefits they gave us in return.

This is the second part of the series I mentioned before. If you haven't read the previous article yet, you can find it here.

Why SSR and Why Next.js?

First of all, as I mentioned in the last article, we didn't choose Next.js or decide to work with SSR just because of common phrases like "we want better performance" or "we want higher Lighthouse scores".

Believe me, you can find many well-engineered CSR applications that outperform SSR applications in these areas.

Our main goal was to load our pages as fast as possible. (ideally without depending on skeleton screens or waiting for client-side rendering).

Also, caching was not only about improving the user experience. It helped us reduce the number of requests hitting our backend services.

By reducing repeated API calls, we could lower the requests per second going to the server, which is also an important part of keeping the system stable under higher traffic.
We wanted Google to be able to crawl our pages easily, and we had some important pages that didn't require much user interaction (client-side JavaScript events).

For example, our home page and the main pages where our products and services were introduced.

These pages acted more like entry points. They allowed users to start their journey and move into other parts of the application.

So we wanted them to be fast, and the characteristics of our product allowed us to achieve that.

That was one of the reasons we chose Next.js. It provided us with many tools and built-in features that helped us solve these problems.

How we did it

So we started developing pages with static-generated params:

and SSR components, making API calls on the server:

and then passing the data to a renderer component like this:

Everything is rendered on the server. The SectionRenderer component itself is also a server-rendered component. This way, we could separate services properly.

This component is responsible for rendering different components based on each section type, and each type can render either CSR or SSR components.

One good thing about SSR and pre-fetching in Next.js is that you can achieve the same goal in multiple ways. You just need to choose the right approach based on your product requirements.

For example, the homepage we talked about could also include a section that displays private, user-based data that needs to be fetched on the client side only.

We can easily define a placeholder model for this section, push it in the sections list (in what ever index), and render a skeleton inside the fully server-rendered page until the data is ready.

We did exactly this on the homepage to a component which was responsible for showing user wallet data:

We could also call and fetch multiple APIs on the server. In our case, we needed to call two APIs in some pages: one to get all the sections we needed to render, and another to fetch the data for those sections.

and after getting all tabs, we could simply decide to render component, only if their tab is sent at the response:

So as I said, there are many different ways to render components and fetch data in Next.js. We just need to decide which approach fits our app best.

Downsides of using pre-fetching and caching

Using these methods definitely has their advantages. First of all, if we use them correctly, the app becomes faster, components load instantly, and everyone is happy.

But wait! not everyone, I assure you :)

When we deployed the first demo pages, the QA team was the first group to “yell” at us :)

They couldn’t easily access the API calls in the Network tab of DevTools, since most of the data was fetched on the server.
It was also harder to understand which API response was responsible for a specific issue.
Even identifying which team was responsible for a bug became more complicated because the API calls were happening on the server.

So for every reported issue, we first had to figure out whether it was caused by the frontend or it was backend bug.

In my opinion, one of the biggest headaches of server-side data fetching is debugging.

And you know what? We didn’t just give the QA team that headache with server-side APIs, we made it even worse by adding a cache layer and NextJs cache component feature to cache the already pre-fetched responses at build time. :)

With caching components and their related data at build time, you can make the application even faster, and maybe even skeleton-free :)

But when you do this, debugging also becomes harder, especially when the backend has its own caching layer (which is usually the case). So if some data changes and you're still seeing old data, you can’t easily say “it’s a backend bug” anymore :)

With this cache component implementation, we didn’t just make QA unhappy, we also dragged the backend team into the pain :)

But why did we put ourselves through all this trouble, and was it really worth it?
In our case, I should say, totally! :)

We made this decision based on the product situation — it wasn’t something we implemented for fun.

In the app, there were a considerable number of components whose data was not expected to change frequently.

Caching this type of data results in faster load times and fewer API calls.

But we didn’t want QA or other teams to suffer from this amazing feature. So we came up with a workaround that allowed other teams to revalidate the cache at runtime.

We built a small utility that rendered an input inside the app, allowing QA to manually revalidate cached data. They could enter the cache tag name (which we provided in a list), and instantly see the updated content.

So in my experience: don’t go for caching components unless you’re sure your app actually needs it — and your product manager explicitly asks for it :)

A Few Notes Before Diving Into Server side API call and Cache Components

Based on my experience with this feature, using use cache can sometimes make things worse, or even hurt both the user and developer experience in certain situations.

So it’s better to use it with caution, and remember: don’t force it into your app. Your app can still feel smooth and fast without it.

Some things I learned:

Use it only when your app can actually benefit from it.
Use it for sections or pages that contain static data, or data that does not change frequently.
Don’t decide to add caching just because you can. This kind of decision is strongly tied to product requirements and should be made with the product team.

Also, if you decide to use caching, it’s better to have a clear cache-time policy that every page or section follows.

In simpler words: avoid hardcoding cache times everywhere. Instead, define a global cache policy and pass the proper value to your cached components.

This way, you know exactly how many cached components you have and how long each section takes to re-validate.

Don’t use cache components for sections that depend on user interaction or are triggered by user events.

Calling APIs on Server + Cache Components | Usage and Workarounds

As I mentioned before, I recommend avoiding cache components for parts of the app that have user interactions. If you cache these parts, you have to deal with some annoying side effects.

But why? And what if you really need caching for those parts?

Let me tell you a story about a situation we faced.

On our vendor page, we had two components related to Comments and Questions. The data inside these sections looked like a good candidate for use cache. They were mostly lists of user comments and questions, and we could re-validate their data from time to time.

But these sections were not just for reading. Users could like comments, write comments, and ask questions.

So when we simply cached these sections, things started to get complicated.

For example, after liking a comment, the section would update at first glance. But after revisiting the page or refreshing it, everything went back to the cached state that had been generated at build time.

This issue was not only related to the like button. New comments, questions, and answers also wouldn’t appear as quickly as users expected.

Another important issue was related to the nature of these sections.

You might say: "Why not keep the cache and just re-validate it after every user interaction?"

We actually tried this. But was it really solving the problem?

Reading comments or questions was not a private, user-specific action. But commenting, asking questions, and liking something were strongly connected to a specific user.

Imagine a user clicked the Like button. We updated the state and changed the button style to show that this user had liked the comment.

But after refreshing the page or visiting it again, even if we had the latest revalidated data and the updated like count, we still couldn't know which exact comment had been liked by this specific user, at least until the user identity was available.

Another problem was that these Comment and Question sections were shared across different pages of the app. Users could interact with them from multiple places, which meant every page needed to display the correct state after user actions.

You might say: "Then just wait until the user data arrives on the client and render these sections."

But my question is: was it really worth adding this much complexity and handling all these side effects just for two components?

Our decision was: hell no. :)

Also, after checking the real impact, we noticed that server-side fetching and caching these sections did not have a significant SEO benefit.

Since these sections were mostly user-driven and interactive, we decided that forcing them into server rendering was not worth the extra complexity.

So we changed the approach completely. We moved these sections to be fetched and rendered on the client side.

Simple, no unnecessary side effects, and no frontend cache problems.

So when it came to user interaction and user-driven features, in my experience, the best approach was usually not to think about server-side API calls and cache components.

But what if you actually need server-side API calls or cache components?

That’s another story.

Again, on our vendor page, we had a section responsible for displaying coupons. Each coupon item was interactive, and users could add them to their cart.

For some reason (let’s just say some SEO stuff 😄), we needed to fetch this data on the server.

Calling APIs on the server and caching the result at build time could be problematic in this case for the exact reasons we talked about before.

But this time, we did both.

We fetched the coupon list on the server, cached it, and then passed the data to the client to handle the user interactions.

But we knew how important it was to keep this list updated and display the correct coupons.

Our vendors could change anything about their coupons: update the remaining amount, close a coupon for some reason, or modify other details. Caching this kind of data without properly handling updates could become a disaster.

So what are the workarounds for handling these situations?

One simple solution is to call the already server-fetched API again on the client side.

But where exactly should we make this client-side API call?

There are different ways to do it, but obviously, you shouldn't place it at the exact same level as the server-side call.

My opinion: do it at the level where the update actually affects the user experience.

For example, in our coupon list, we rendered an "Add" button for each coupon that was available to be added to the cart. So we triggered the client-side API call at that level.

Our client-side API calls were handled with React Query, which also provides caching for API responses. This means that no matter how many coupon items used this hook, the API request would only be made once.

So we called the related hook there and compared the client-fetched data with the data we received from the server. If anything had changed, we could update the UI accordingly.

And then, if isInFreshList was false, we could either unmount the Add button completely or simply hide it to avoid unnecessary layout recalculations

Here is another workaround, this one is related to loading and using Suspense when working with server-side API calls and pre-fetching.

This workaround was actually from one of our talented colleague.

When working with server-side APIs, we should always consider wrapping components that need to wait for data with Suspense.

This way, we don’t pause the rendering of the whole page just because one or two components.

Something like this:

The thing is, the fallback doesn’t always need to be a placeholder or a skeleton. We could actually use the pre-fetched data we already had from build time and pass that component as the fallback of the Suspense boundary.

Then the main component, which is responsible for fetching the fresh data, could load in the background and replace the fallback once the latest data was ready.

You can use this method, especially when you have to deal with query params on your page.

You can’t pre-fetch every possible combination of params, but you can pre-fetch the main API and use its result as a placeholder until the client-side API call is completed.

Of course, users might see previous data for a second, and from your perspective, it might look like a bug.

But in my opinion, using this workaround for sections that are not critical can actually be a very clever hack!

So in this article, I shared my experiences working with SSR and cache components.

In the next article, I will talk about our client-side caching system, how we used React Query, how we handled serving pages from CDN, and the challenges we faced along the way.

Navigation State | components communication in React - final part

Mohan Sebastian — Fri, 27 Jun 2025 11:02:27 +0000

This is the final part of my exploration into state management and data structures.
In the previous section, we discussed the CustomEvent and EventTarget APIs, and how they can be used to build a Pub-Sub-like communication system between components.

In this part, I want to introduce another native method for transferring data — one of React's built-in features within its routing system (react-router) that can greatly simplify our work. But before that, it's important to understand that React Router works closely with the browser's History API. So whenever we use hooks like useNavigate or useLocation, we're actually interacting with native browser functionality under the hood.

Relationship between react-router and the History stack

Obviously react-router use winow.history to manage navigation and state transitions.

The History Stack is part of the browser’s navigation system and it allows pages to:

Push new entries (pushState)
Replace the current entry (replaceState)
Navigate backward and forward

So when we’re using method like navigate(“/some-url”), its internally doing:

Another navigation API available in the browser is window.location.href. We can reassign this property to navigate to a different URL. However, React Router and most SPA frameworks rely on the pushState and replaceState methods instead — and here’s why:

pushState:

Doesn’t reload the page
Adds a new entry to the browser’s history stack
Allows passing state as a payload to the next page
Ideal for SPAs

In contrast, window.location.href behaves like a traditional link. It performs a full page reload and is commonly used for navigating to external domains or outside the current application.

Now you can see how data transfer works in React Router.
As mentioned earlier, the pushState and replaceState methods allow us to pass data as a payload when navigating between pages in a single-page application.

Don’t worry about the second argument — it’s the title property, but most browsers ignore it. It was originally intended to set the page title shown in the browser history. (modern browsers rarely support or use it.)

Now let's use this inside React using useNavigate and useLocation. Imagine we want to send some data from the Home page to another page named Article

First we import useNavigate hook from react-router-dom and then call it with a string as url and an object with a state prop as payload.

Now inside the Article page:

We import useLocation from react-router-dom and use the state prop to get our data.

Note

As I mentioned, the useNavigate hook preserves data in the history stack. However, we need to remember that this state is not the same as React's internal state created with the useState hook. The navigation state, which we accessed earlier using useLocation, persists across page reloads so remember to remove it after you’re done with it.
We can do this using the useNavigate hook by passing location.pathname as the URL and an empty object as the state payload.

The navigation state is a simple and handy way to transfer state between two pages. One of its most important uses is tracking the user's last visited page within the current session.

In our project, I used this method to navigate the user from the Orders page—along with data related to a specific order—to the Shop page, where I used that order data to create a new basket for reordering.

You can try it for yourself and reorder something from the site — of course, you need to have a completed order first. :)
https://www.digikalajet.com/profile/orders

Next.js does not support navigation state, so it's not possible to pass a payload directly through router.push or router.replace. Instead, you can use alternatives like query parameters or persist the data in localStorage.
Next.js uses a file-based routing system and is designed with SSR. Browser-side state like a navigation payload would be lost unless passed via the URL or stored globally (like I said, in a context, Redux, or localStorage).

Mohsen Khademhosseini
github
linkdin

EventTarget - CustomEvent | components communication in React - part Three

Mohan Sebastian — Tue, 06 May 2025 18:11:52 +0000

In the first and second parts, we focused on creating two different patterns for handling data flow in React.
In this part—and the one that follows, we’ll explore how to manage component communication using Web APIs and React’s built-in capabilities.

What is EventTarget

EventTarget is the foundation of the browser’s event system.
It’s a built-in interface that enables objects to handle events through methods like addEventListener, removeEventListener, and dispatchEvent.

Many core Web APIs including DOM elements like <button>, <div>, <input>, as well as document and window inherit from EventTarget.
That’s exactly why we can do things like:

How the Event system works in the browser

When we attach an event handler to a DOM element—like in the picture above—we’re actually subscribing to that element through one of its event channels.
In this case:

The button is the publisher (or emitter)
The callback function passed to addEventListener is the subscriber (or listener)

So when a user clicks the button, the button emits a 'click' event, and all registered listeners for that event type are notified and executed.

So with the EventTarget constructor, we can both publish and subscribe to built-in or custom events.
But how do we create different types of events and pass custom data with them?
That’s where the CustomEvent constructor comes in.

CustomEvent

CustomEvent allows us to define our own event types beyond the built-in types (like “click”,”change”, “keydown”) and include any kind of data through the detail property.

After that we able to use any DOM element as the publisher for emitting this event. like this:

We’re using the document as the publisher for our custom event.

And after this any listener that subscribed to document using addEventListener(“eventName”,....) will be notified.

Good to Know: What Pattern does the Browser Event System Follow?

The event system in the browser shares similarities with both the Observer and Pub-Sub patterns.
When you attach a listener directly to a DOM element, that element acts as the subject, keeping track of its observers (callback functions). In this context, we're clearly in the Observer area.

However, when you use the EventTarget constructor to create a standalone event system not dependent on a specific DOM element—it behaves more like the Pub-Sub pattern, where publishers and subscribers are loosely coupled and communicate through named events.

The key difference between DOM-events and custom events lies in their level of coupling. Custom events are decoupled, meaning the publisher and subscriber don’t hold direct references to each other but DOM events are tightly coupled because listeners are directly attached to specific elements.

The more decoupled our communication becomes, the closer it aligns with the Pub-Sub pattern. The browser’s event system isn’t a strict implementation of either Pub-Sub or Observer, it draws inspiration from both.

Implement Custom Event System in React with EventTarget

This setup is very similar to the Pub-Sub pattern from the first article, but this time we use the browser’s built-in APIs instead of writing everything from scratch.

First, we define an EventTypes object to list all our event names and their corresponding payloads. This ensures our pub-sub implementation remains fully type-safe:

Later, we'll use the keys of EventTypes as event names and their corresponding values as the payloads when calling the emit function.

Next, we create an EventTarget instance. As mentioned earlier, this constructor gives us access to event-related methods like addEventListener and dispatchEvent without needing to attach them to DOM elements.

Our next step is creating the emit function which allows us to publish events:

This method works similarly to the emit function we discussed in the first article. It accepts an eventName and a payload as parameters. However, this time we use the CustomEvent API to create an event instance, passing the eventName and payload as arguments. This event is then dispatched using the dispatchEvent method of the eventTarget instance, triggering the event and making it available for listeners.

Finally, we create our subscribe function, which allows us to listen to the emitted events. It takes an eventName and a callback function as parameters.

We defined a handler that will be executed when the event is dispatched. This function receives the event as an argument, and we pass it to a CustomEvent to access the detail property, which contains the event's data.

When you call subscribe, you're essentially telling your application to "listen" for a specific event (with a specific eventName) and provide a callback function that will be called when the event is triggered.
This sets up the handler function, but nothing happens yet. The handler function doesn't execute at this point; it's just registered to listen for events.

The subscribe function returns an unsubscribe function, which will be used later to remove the listener and prevent memory leak.

If you're interested, you can clone this repo and try out the event system yourself.

Mohsen KhademHosseini - Mohan
Linkdin
github

Observer pattern | components communication in React - part two

Mohan Sebastian — Sat, 26 Apr 2025 16:35:30 +0000

In the first part of this article, I talked about the Pub-Sub pattern — a simple and effective way to share data without strictly following React’s unidirectional data flow.
In this part, I’ll talk about another system called the Observer Pattern. Like Pub-Sub, it doesn’t follow React’s top-to-bottom hierarchical data flow — but it approaches the problem in a slightly different way.

If this is how the Pub-Sub pattern manages data sharing:

Event bus / event channel is where we store the events.

The observer pattern is something like this:

As you might have noticed from the pics, there are some key differences between the two patterns:

In Pub-Sub, the publisher sends the event to an event channel, and the subscriber listens for a specific event name.
In the Observer pattern, observers (subscribers) register directly with the subject (publisher) and get notified when its state changes.

In the Pub-Sub pattern, the publisher doesn’t know anything about its subscribers, while in the Observer pattern, the subject holds direct references to its observers.

About observer Pattern

The observer pattern is another way to work around React’s top-down data flow.
In this pattern, we’ll talk a lot about two main concepts: Subject and Observers.
You can think of the Subject as the Publisher and the Observer as the Subscriber in the Pub-Sub pattern. (While they’re not exactly the same, this comparison might help you better understand their responsibility.)
In this pattern, we have a main object called the Subject, which stores and manages a state. It also keeps track of a list of other objects, called Observers, which are notified whenever the state changes.

This pattern is another way to work around React's unidirectional data flow. It allows you to update the state from any component and access the updated state wherever it's needed.

Enough talking! Let's put it into action and build our Observer utility.

What we’ll build:

A Subject which holds and update the state
Multiple Observers which can subscribe the state updates
A custom hook for using this functionality in react

Creating a Subject function

This function will be responsible for storing and updating the subject’s state. It receives an initialValue, which will be our first state.

As before in the Pub-sub pattern, we use generics to make this utility flexible and type-safe. It allows us to define what type of data this subject will manage, so we get full TypeScript support when we want to set or read the state.

Storing Observers and value

Next we create a variable called value and assign the initValue to it.

The reason we do this is that we want to reassign this value over time. Whenever a new state is introduced, we will update this value variable accordingly.

In the next line we created another variable to store our observers. As we said, we use observers to listen/subscribe to any state changes.
We might have multiple observers in different pages or components so a new Set is a suitable approach for storing this type of data.

Using the Set constructor ensures that a function can't be registered multiple times. It also offers faster operations for adding, removing, and checking items _O(1) _ compared to an array.

Creating a subscriber function

This function takes an observer as its argument, adds it to the list of observers for future updates, and immediately invokes the observer with the current value (which at first was initially set when createSubject was called).

At the last lines, we return a callback to clean up the subscribed observer from the observers list.
The reason for this is exactly like what we did in our Pub-sub implementation: to avoid memory leaks and prevent multiple updates caused by repeatedly mounting and unmounting components.

Updating state

We created a function called next. This function receives a new value, replaces the old one, and then updates each observer by calling them with the new value. This way, all observers are notified of the latest update.

Both subscribe and next functions call observers, but they serve different responsibilities:

subscribe is responsible for the initial setup. It registers observers when they want to start listening to the subject. It’s called once, and immediately notifies the observer with the current state.
next updates the internal value with a new state and then notifies all registered observers about this change.

So in short:
subscribe registers and notifies about the current state,
next updates the state and notifies about the new state.

Getting the Value

In the final step, we create a simple function called get, which returns the current value. We'll use this function to access the latest value at any time, especially when we need to read it or update it with a new one.
Finally we expose these three functions for external use.

Subscribing to the Observer: Creating the Custom Hook

This custom hook lets us subscribe to a subject and automatically triggers a re-render whenever the subject’s value changes.

This hook receives the subject as an argument. It initializes a useState with the subject’s latest value, giving us access to the current state. Then, we use a useEffect hook to subscribe to the subject when the component mounts, this way we ensure the initial value is displayed and updates are tracked.

This Is Where the Magic Happens!
As you might have noticed in the code, we passed our setState function to the subscribe method of our subject. This is a very important step — it's what makes the hook reactive and keeps the component updated.

The setState function is actually acting as our observer. Later on, you'll see how we update the state using the next function, like this:

In this example, we call next with the current value (retrieved using get) and increment it by one. Here's what happens inside the next function:

This function updates the internal value and then notifies all registered observers by calling them with the new value. Since our observers are actually setState functions, we’re triggering a React state update and that causes a re-render of any component using this hook.
A similar thing happens inside the subscribe function: it receives the setState function as an argument, adds it to the observers set, and invokes it immediately with the current value to sync the initial state.

At the end we expose the state (which is our latest updated value) for the external usage.

Final Part: Putting everything to use

First, let’s create an instance using our createSubject function. This instance will hold a number and allow us to update it by one. We can create a file called store.ts and add our instances there:

Now we can use our instance in any page we want. I used it inside my Home page and call it’s next method to update its initial state by one:

You can click this button as much as you like and still access its latest state in any component or page you need. Pretty incredible, right?
Here’s how I subscribed to the count subject in my Counter page:

A Twist For Those Who Aren't Tired Yet!

The Observer pattern is a widely used system for managing data and communication between different parts of an app. Many methods and libraries have taken inspiration from this practical approach.
The useEffect hook is a great demonstration of how this pattern has inspired core concepts in React.
The core idea of the Observer pattern is subscribing to changes and reacting whenever something happens. An observer listens to a subject and gets notified whenever the subject’s state changes. This concept is quite similar to how React’s useEffect hook works.

In React, the useEffect hook allows components to respond to changes in their environment, such as updates to props or state by running side effects when those changes occur.

Also, some web APIs like window.addEventListener are inspired by the Observer pattern.

If we look more deeply, we can say that state management libraries like Redux have also borrowed some ideas from this pattern.

Redux isn't a pure Observer pattern implementation, but it shares some similarities: we could count the store as the subject, components subscribe or listen to the store via selectors, and we can trigger state changes by dispatching actions. When that happens, all the subscribers get notified and can react accordingly.

The Observer Pattern in React: Why It Matters and Where It Fits

As you all know, we have tons of state management libraries for handling component communication. Among them, React’s Context API stands out as a very powerful and straightforward way to manage state and as we said, many of these tools share core ideas with the Observer pattern.

That raises a very valid question — if we already have these libraries and APIs, why the hell would we need to implement our own observer logic to manage data flow?

I don’t want to give you a headache by over explaining this, because honestly—the answer is simple: we don’t need to! We’ve got Context, Redux, and plenty of other libraries ready to use.

But

Choosing the Observer pattern over these tools isn’t about simplicity or being lightweight. It’s about the nature of the data we’re trying to share.

If we’re working with data that needs to be accessed across the entire app, we should lift it up—put it in the top-most layer and treat it as a global state. But if we’re just trying to share some data between two pages or non-parent-child components, the Observer pattern can actually be a smart choice.

Then if we’ve noticed that we’re creating too many observers or subscribing all over the place, it’s time to pause and rethink. The Observer pattern isn’t a great fit when data is used widely in the app. It can make state harder to trace and seriously hurt the developer experience.

If you're interested, you can check out my repo and try using the Observer pattern yourself.
Mohsen KhademHosseini - Mohan

Pub-sub pattern | components communication in React - part 1

Mohan Sebastian — Thu, 17 Apr 2025 19:42:33 +0000

This article aims to explain React's unidirectional data flow and answer the question: are there any ways to work around it?
And based on this subject, I will take a look at different libraries and methods for sharing data and communication between components.

But first, I'd like to explain my understanding of data flow in React.

As I said, React has a one-way data flow. This means the data can only move from top to bottom — and by this, I mean whenever you have some data or state that you want to share between multiple components, you should lift that state up to the nearest parent component and then pass it down via props.

For better understanding, we can think of React data management like a river system:
Data starts at a main source (the parent) and flows to branches (the children).
Child components cannot push water back to the main river.
Only one direction is possible unless special mechanisms (like lifting state up) are used.

We can say that in a React application, the main source is the Root component, which acts as the entry point for rendering the entire React component tree.
So, if the Root component (which is usually the App.tsx file in our project) is the source of all other components, this is the best — and only — place to store global states.
This is where we use tools like Redux, Context, or other global providers.

Then, from the Root, we can access the other components or branches of the React application system.
And since routing needs to be defined at the top level of the app, the Root component is the suitable place for wrapping the React Router, allowing the application to handle different pages and navigate between them.

With this understanding of the React component tree, let's explore some different ways to access and store data in React.
Rather than discussing libraries or methods like Redux or Context (which I assume you’re already familiar with), I will focus on other patterns and systems that we can create to manage data accessibility.(Let’s just say workarounds!)

Publish-Subscribe pattern

This pattern is a suitable approach for communication between components / pages in any hierarchical location.

create a functionality for emitting or publishing an event:
First, we need to create a variable that stores the eventName along with the value of that event. A Map constructor would be a great choice for this responsibility.

For enlightenment this is inside the EventTypes:

This way we have a more strict way for setting event names and values.

Now let's create an emit function for publishing events:
This function receives a key (which must be one of the keys defined in EventTypes) and a value (strictly typed based on the related type in EventTypes).
The reason for this pattern is to prevent typos and to ensure a better DX.

By using EventTypes as a source of truth, we can't accidentally use a random string as an event name or pass an incorrect value (payload). This way we can work with events very easier across the app.

Create another functionality for listening or subscribing to an event:

At this step we create a variable to store the event that we want to listen to by calling the subscription function.

The subscribers variable also is a Map constructor, it takes an eventName as a key and a callback as a value. This callback function is responsible for accessing the data that we emitted somewhere in the app.

Now it's time to create a subscription function:

As we said,the subscribe function takes an eventName as a key and a callback, which receives the exact data stored in eventStore for that key as its parameter.

In both emit and subscribe functions, we use TypeScript generics to tell the compiler which event is being used and what type of data it should expect, ensuring everything stays typed and consistent.

Let’s explain inside of the function:
In the first condition we check if the subscribers store is empty. If it is, we add the eventName as a key and initialize its value by a Set constructor.

We used Set for ensuring that the same callback isn’t added multiple times for the same eventName.

In the next line we’re trying to reach the event by passing that key parameter to the subscribers store and then add the callback (second parameter) to it as a value.

First We initialized a subscriber with a Set constructor. Then we added the receiving callback to it.
Adding the key and its callback to the subscribers store allows us to unsubscribe/clear the event after it's been published.

In the last condition, we check if the eventStore already contains a value for the given key. If it does, we immediately call the callback with that value.

Last part - Unsubscribing from the event:

Before explaining the code, let’s talk about the purpose of unsubscribing from an event. Why should an event be cleared or removed after it has been published?

The answer is easy and short: to avoid memory leaks!

With unsubscribing an event, we’re actually removing the reference to that callback, and this will help garbage collection work properly.
Also, if we don't unsubscribe from an event, the logic might be triggered multiple times when only a single response was expected, which can lead to unexpected behavior in the app.

In our unsubscribe function, we first check if the key exists in the subscribers store. If it does, we simply delete that entry from the store.

That’s the whole idea behind the pub-sub pattern. Now, let’s see it in action!

Using Emit method for creating an event

Imagine this is our home page and we want to navigate users to the dashboard page and also inform the page about some data.
When the user clicks on the Button, the emit function will be called, an eventName with a payload will be created and stored in the eventsStore. Then we navigate the user to the dashboard page.

Using subscribe/unsubscribe for listening/clearing an event

In the Dashboard page, we wrap our subscribe function inside a useEffect hook to ensure that everything is properly mounted before the event is received.
We call the subscribe function with a callback, where the data parameter represents the exact value that was emitted earlier from the Home page using the emit function.

In the cleanup part we use the unsubscribe method to clear the event after we reach it.

The reason that we must call these two methods inside the useEffect is that we must be sure that the component is fully mounted and its state is ready and accessible. Also if we call subscribe directly in the component we trigger it after each render and that could cause duplicated responses and memory issues.

This pattern helps us establish faster communication between components or pages. We can improve it further by creating a custom hook like useEventEmitter, which handles component mounting internally, so we don’t have to use useEffect every time we want to listen to an event.

you can see the eventEmitter.ts in my github repo.

Also, feel free to check out these articles if you're interested in exploring this pattern further:

Implementing a Pub-Sub Based State Management Tool in React
pub-sub pattern in react
Leveraging React Event Emitter for Seamless Component Communication

*In the next article I will talk about another way of communication between components. *

Mohan KhademHosseini
www.linkedin.com/in/mohsen-khadem-hoseini-07590b211
https://github.com/mohsenKh75