DEV Community: Mohsen Khadem Hoseini

Navigation State | components communication in React - final part

Mohsen Khadem Hoseini — 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

Mohsen Khadem Hoseini — 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

Mohsen Khadem Hoseini — 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

Mohsen Khadem Hoseini — 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