DEV Community: Maksim

Bridging RxJS BehaviorSubject and React with useSyncExternalStore

Maksim — Wed, 09 Sep 2026 19:56:04 +0000

If you keep shared, mutable state in an RxJS BehaviorSubject — a WebSocket connection status, a design-system theme, a cache shared between routed pages — you eventually need to read that state from a React component and re-render when it changes. For years the answer was a hand-rolled useEffect + useState subscription, react-rxjs, or useObservable from some utility library.

Since React 18 there's a built-in, purpose-built hook for exactly this: useSyncExternalStore. It's the same primitive Redux, Zustand, and Jotai use under the hood, and it plugs into a BehaviorSubject almost for free — because a BehaviorSubject already is an external store: it holds a current value (getValue()) and lets you subscribe to changes.

This post walks through wiring the two together, the two gotchas that will bite you if you skip them, and how to select a slice of a larger observable state without over-rendering.

The store contract

useSyncExternalStore takes two functions and returns the current value:

const value = useSyncExternalStore(subscribe, getSnapshot);

subscribe(onStoreChange) — subscribe to the store, call onStoreChange whenever it changes, return an unsubscribe function.
getSnapshot() — return the current value. It must return the exact same reference if nothing changed; React compares snapshots with Object.is to decide whether to re-render.

A BehaviorSubject maps onto this directly: subject.subscribe(fn) is your subscribe, and subject.getValue() is your getSnapshot.

A minimal adapter

import { BehaviorSubject } from "rxjs";
import { useSyncExternalStore, useCallback } from "react";

export function useBehaviorSubject<T>(subject: BehaviorSubject<T>): T {
  const subscribe = useCallback(
    (onStoreChange: () => void) => {
      const subscription = subject.subscribe(onStoreChange);
      return () => subscription.unsubscribe();
    },
    [subject]
  );

  const getSnapshot = useCallback(() => subject.getValue(), [subject]);

  return useSyncExternalStore(subscribe, getSnapshot);
}

Usage:

// store.ts
export const connectionStatus$ = new BehaviorSubject<"online" | "offline">("online");

// ConnectionBadge.tsx
function ConnectionBadge() {
  const status = useBehaviorSubject(connectionStatus$);
  return <span>{status === "online" ? "🟢" : "🔴"}</span>;
}

That's the whole integration. Two details make the difference between "works" and "resubscribes on every keystroke and eventually falls over."

Gotcha #1: stabilize `subscribe`

useSyncExternalStore resubscribes whenever the subscribe function reference changes. If you define it inline in the component body without useCallback, it's a new function on every render, so React tears down and re-creates the RxJS subscription on every render too — wasteful at best, and a source of subtle timing bugs (a store change firing between unsubscribe and resubscribe can be missed) at worst:

// Don't do this — new closure every render, resubscribes constantly
function ConnectionBadge() {
  const status = useSyncExternalStore(
    (cb) => {
      const sub = connectionStatus$.subscribe(cb);
      return () => sub.unsubscribe();
    },
    () => connectionStatus$.getValue()
  );
  ...
}

Wrapping it in useCallback (as in the adapter above), or — better — defining subscribe/getSnapshot once outside the component when the subject itself is module-level, fixes it:

// subject is module-level, so subscribe/getSnapshot can be too
const subscribe = (cb: () => void) => {
  const sub = connectionStatus$.subscribe(cb);
  return () => sub.unsubscribe();
};
const getSnapshot = () => connectionStatus$.getValue();

function ConnectionBadge() {
  const status = useSyncExternalStore(subscribe, getSnapshot);
  ...
}

Gotcha #2: never synthesize a new object in `getSnapshot`

React uses Object.is on whatever getSnapshot returns. BehaviorSubject.getValue() returns the stored reference as-is, so as long as you don't transform it in getSnapshot, you're safe:

// Fine — same reference until the subject emits a new one
const getSnapshot = () => connectionStatus$.getValue();

// Broken — new object every call, infinite render loop
const getSnapshot = () => ({ status: connectionStatus$.getValue() });

If you need a derived value (a slice of a bigger state object, a computed flag), derive it in RxJS before it reaches getSnapshot, with distinctUntilChanged so the underlying subject only "changes" (from the hook's point of view) when the derived value actually changes. That's the selector pattern below.

One quiet behavior worth knowing

BehaviorSubject calls its subscriber synchronously and immediately with the current value on subscribe(). That means the onStoreChange callback you pass to useSyncExternalStore fires once, synchronously, during the initial subscribe — before any real change happened. This is harmless: getSnapshot() at that point returns the same reference useSyncExternalStore already has, so Object.is short-circuits and no extra render happens. Worth knowing mainly so it doesn't look like a bug the first time you log inside subscribe.

Selecting a slice, with plain RxJS

A single BehaviorSubject often holds more than one component needs — a whole app-state object, say. If every consumer just called useBehaviorSubject(state$), every consumer would re-render on any change to that object, even to fields it doesn't read.

You don't need another package for this — RxJS already ships the tool: map + distinctUntilChanged. Turn the selection into its own observable, and feed that into useSyncExternalStore instead of the raw subject.

The one wrinkle is that getSnapshot has to be synchronous and callable at any time, while the derived observable only pushes a new value when something changes. So the adapter needs a small mutable cell that holds "the last selected value," seeded synchronously and updated by the subscription:

import { BehaviorSubject } from "rxjs";
import { map, distinctUntilChanged } from "rxjs/operators";
import { useSyncExternalStore, useMemo } from "react";

function useSelectFromSubject<T, R>(
  subject: BehaviorSubject<T>,
  selector: (state: T) => R
): R {
  const { subscribe, getSnapshot } = useMemo(() => {
    const selected$ = subject.pipe(map(selector), distinctUntilChanged());
    let current = selector(subject.getValue()); // synchronous initial value

    const subscribe = (onStoreChange: () => void) => {
      const sub = selected$.subscribe((value) => {
        current = value;
        onStoreChange();
      });
      return () => sub.unsubscribe();
    };
    const getSnapshot = () => current;

    return { subscribe, getSnapshot };
  }, [subject, selector]);

  return useSyncExternalStore(subscribe, getSnapshot);
}

A component that only cares about count never re-renders when user changes:

interface AppState {
  user: { name: string };
  count: number;
}

const state$ = new BehaviorSubject<AppState>({ user: { name: "Max" }, count: 0 });

function Counter() {
  const count = useSelectFromSubject(state$, (s) => s.count);
  return (
    <button onClick={() => state$.next({ ...state$.getValue(), count: count + 1 })}>
      {count}
    </button>
  );
}

Two things to watch with this version:

The selector passed to useMemo's dependency array needs a stable reference (define it outside the component, or wrap it in useCallback) — otherwise useMemo rebuilds the observable and resubscribes on every render, the same problem as gotcha #1.
distinctUntilChanged compares with === by default, so it works out of the box for primitives (like count) but not for selectors that return a new object or array each time. Pass your own comparator — distinctUntilChanged((a, b) => shallowEqual(a, b)) — if the selected slice isn't a primitive.

I checked this against a small harness that mimics React's Object.is-comparison loop: updating user alone never triggered the count selector's onStoreChange, while updating count did — exactly the isolation you want from a selector, with nothing beyond rxjs and react in the dependency tree.

Server-side rendering

If you render on the server, pass a third argument — getServerSnapshot — or React throws during SSR. For a BehaviorSubject, that's usually just the value it was seeded with:

const status = useSyncExternalStore(
  subscribe,
  getSnapshot,
  () => "online" as const // value to use during SSR/hydration
);

Why this beats the `useEffect` version

The naive alternative — useState seeded from getValue(), updated in a useEffect subscription — works, but has two problems useSyncExternalStore was built to fix: it can tear during concurrent rendering (a component can read a stale value mid-render because the subscription updates state after render, not during it), and it doesn't support startTransition/Suspense-aware scheduling correctly. useSyncExternalStore reads the store synchronously during render, so what you see on screen is always consistent with the actual subject value, even under concurrent features.

Summary

BehaviorSubject.subscribe / BehaviorSubject.getValue() map directly onto useSyncExternalStore's subscribe / getSnapshot.
Keep subscribe and getSnapshot referentially stable (module-level functions, or useCallback) — an unstable subscribe resubscribes on every render.
Never build a new object inside getSnapshot; return the subject's value as-is.
For a derived slice of a larger state object, pipe the subject through map + distinctUntilChanged and feed that derived observable into useSyncExternalStore instead of the raw subject, so unrelated field changes don't re-render every consumer.
Pass getServerSnapshot if you render on the server.

The whole point of useSyncExternalStore is that it's a narrow, boring primitive — which is exactly what makes it a good fit for something like RxJS that already models "current value + subscription" as its core abstraction.

Data Structures: Bidirectional Map

Maksim — Mon, 06 Sep 2021 10:13:14 +0000

In computer science, a bidirectional map is an associative data structure in which the (key,value) pairs form a one-to-one correspondence. Also known as bijective map. Article on Wikipedia.

It is not widely used data structure in web development, but in some cases really quite useful, for instance in encryption.

Let's describe our goal. Implement data structure, where following operations are performed in constant time:

Get value by key
Get key by value
Remove record by key
Remove record by value
Check for the existence of key
Check for the existence of value
Get the size of the map

Implementation below:

class BidirectionalMap<Key, Value> {
  private readonly map: Map<Key, Value>;
  private readonly inverseMap: Map<Value, Key>;

  constructor() {
    this.map = new Map();
    this.inverseMap = new Map();
  }

  clear(): void {
    this.map.clear();
    this.inverseMap.clear();
  }

  deleteKey(key: Key): boolean {
    if (!this.hasKey(key)) {
      return false;
    }

    const value = this.getValue(key)!;
    this.inverseMap.delete(value);
    return this.map.delete(key);
  }

  deleteValue(value: Value): boolean {
    if (!this.hasValue(value)) {
      return false;
    }

    const key = this.getKey(value)!;
    this.map.delete(key); 
    return this.inverseMap.delete(value);
  }

  entries(): IterableIterator<[Key, Value]> {
    return this.map.entries();
  }

  getKey(value: Value): Key | undefined {
    return this.inverseMap.get(value);
  }

  getValue(key: Key): Value | undefined {
    return this.map.get(key);
  }

  hasKey(key: Key): boolean {
    return this.map.has(key);
  }

  hasValue(value: Value): boolean {
    return this.inverseMap.has(value);
  }

  get isEmpty(): boolean {
    return this.size === 0;
  }

  keys(): IterableIterator<Key> {
    return this.map.keys();
  }

  set(key: Key, value: Value): void {
    if (this.hasKey(key) || this.hasValue(value)) {
      throw new Error('Key or Value already exists');
    }

    this.map.set(key, value);
    this.inverseMap.set(value, key);
  }

  get size(): number {
    return this.map.size;
  }

  values(): IterableIterator<Value> {
    return this.inverseMap.keys();
  }
}

Basically we can consider this data structure as extending of Map class. Current implementation could be improved by adding forEach method and iterable protocol, which will allow to define iteration behavior of Bidirectional Map. Let me know in comments if your interesting to know, how to do it exactly.

How to get month list in your locale

Maksim — Thu, 04 Jun 2020 10:01:21 +0000

Hi there! I am glad to show simple TypeScript function, that maybe will save your time. In many cases you need to implement selector of months. In some cases it should be in different locales. See it below:

function getMonthList(
  locales?: string | string[],
  format: "long" | "short" = "long"
): string[] {
  const year = new Date().getFullYear(); // 2020
  const monthList = [...Array(12).keys()]; // [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11]
  const formatter = new Intl.DateTimeFormat(locales, {
    month: format
  });

  const getMonthName = (monthIndex: number) =>
    formatter.format(new Date(year, monthIndex));

  return monthList.map(getMonthName);
}

That's it. Just provide your locale as param.
For example, 🇬🇧 getMonthList('en') will return:

January
February
March
April
May
June
July
August
September
October
November
December

Try it by yourself on codesandbox.

For short version of names just provide second param as short.
For example, 🇬🇧 getMonthList('en', 'short') will return:

Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec

Follow me in Twitter

Update
By your requests I have extracted function in package

Power in tiny libraries

Maksim — Tue, 07 Jan 2020 11:48:03 +0000

Hello there!

Weight of your client side bundle is very important for best user experience. Users do not like to wait. For this purpose I am interesting to find tiny analogs of most popular libraries. I know next ones:

Do you know something else?

Typescript and Redux. My tips.

Maksim — Thu, 21 Nov 2019 10:32:29 +0000

Introduction

Hello everybody!

Today I want to talk about quite popular technologies. Typescript and Redux. Both helps to develop fault tolerant applications. There is a lot of approaches to write typings of state and actions. I formed own, that could save your time.

State

Each state in Redux should be immutable. Immutable object cannot be modified after it is created. If you forget this rule, your component do not rerender after state changes. So let's use Readonly modifier. It makes all properties readonly. You can't mutate property in reducer.

export type State = Readonly<{
  value: number;
}>

Do not forget use Readonly modifier for nested objects too. But what about arrays. For example:

export type State = Readonly<{
  list: number[];
}>

You still can change it. Let's fix it, TypeScript includes special modifier ReadonlyArray.

export type State = Readonly<{
  list: ReadonlyArray<number>;
}>

Now you can't add or remove items. You have to create new array for changes. Also TypeScript has special modifiers for Map and Set: ReadonlyMap and ReadonlySet.

Actions

I use enums for Redux actions. Naming convention is simple: @namespace/effect. Effect always in past tense, because it is something already happened. For example, @users/RequestSent, @users/ResponseReceived, @users/RequestFailed...

enum Action {
  ValueChanged = '@counter/ValueChanged',
}

Action creators

Little magic starts.

The first thing, we use const assertions. The const assertion allowed TypeScript to take the most specific type of the expression.

The second thing, we extract return types of action creators by type inference.

const actions = {
  setValue(value: number) {
    return {
      payload: value,
      type: Action.ValueChanged,
    } as const;
  },
}

type InferValueTypes<T> = T extends { [key: string]: infer U } ? U : never;

type Actions = ReturnType<InferValueTypes<typeof actions>>;

Let's improve it by helper function:

export function createAction<T extends string>(
  type: T,
): () => Readonly<{ type: T }>;
export function createAction<T extends string, P>(
  type: T,
): (payload: P) => Readonly<{ payload: P; type: T }>;
export function createAction<T extends string, P>(type: T) {
  return (payload?: P) =>
    typeof payload === 'undefined' ? { type } : { payload, type };
}

Then our actions object will look:

const actions = {
  setValue: createAction<Action.ValueChanged, number>(Action.ValueChanged)
}

Reducers

Inside reducer we just use things described before.

const DEFAULT_STATE: State = 0;

function reducer(state = DEFAULT_STATE, action: Actions): State {
  if (action.type === Action.ValueChanged) {
    return action.payload;
  }

  return state;
}

Now, for all of your critical changes inside action creators, TypeScript throws error inside reducer. You will have to change your code for correct handlers.

Module

Each module exports object like this:

export const Module = {
  actions,
  defaultState: DEFAULT_STATE,
  reducer,
}

You can also describe your saga inside module, if you use redux-saga.

Configure store

Describe the whole state of application, all actions and store.

import { Store } from 'redux';

type AppState = ModuleOneState | ModuleTwoState;
type AppActions = ModuleOneActions | ModuleTwoActions;

type AppStore = Store<AppState, AppActions>;

Hooks

If you use hooks from react-redux, it would be helpful too.
By default you need to describe typings each time, when you use this hooks. Better to make it one time.

export function useAppDispatch() {
  return useDispatch<Dispatch<AppActions>>();
}

export function useAppSelector<Selected>(
  selector: (state: AppState) => Selected,
  equalityFn?: (left: Selected, right: Selected) => boolean,
) {
  return useSelector<AppState, Selected>(selector, equalityFn);
}

Now you can't dispatch invalid action.

The end

I hope all of this things will make your live easier.
I will glad for your comments and questions.
My twitter.

Typescript. Simple React components.

Maksim — Tue, 27 Aug 2019 07:39:14 +0000

Hello there. I very like to use React and Typescript. Almost in each new project need simple components, like atoms, for example: button, input, checkbox etc. I have some best practices to make it friendly for all members of team, but also with strict typings. Let's get a look, maybe it will be helpful for you too.

Button

import React from 'react';

interface IProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
  block?: boolean; // Your some custom prop
}

export const Button: React.FunctionComponent<IProps> = ({ block, children, ...shared }) => {
  return <button {...shared}>{children}</button>;
}

Button.defaultProps = {
  type: 'button',
}

That's it. You have custom Button component, that supports all native button attributes with strict typings. You can put common things for all buttons in project, like styles or some business logic.

For use

import React from 'react'

instead of

import * as React from 'react'

add in your tsconfig.json property esModuleInterop: true

Input

import React from 'react';

interface IProps extends Omit<React.InputHTMLAttributes<HTMLInputElement>, 'onChange' | 'value'> {
  value: string;

  onChange(value: string): void;
}

export const Input: React.FunctionComponent<IProps> = ({ children, onChange, ...shared }) => {
  return <input onChange={e => onChange(e.target.value)} {...shared} />;
}

Input.defaultProps = {
  type: 'text',
};

The Omit helper type was added in Typescript 3.5. If you use previous version of Typescript, just add this string:

type Omit<T, K> = Pick<T, Exclude<keyof T, K>>

Checkbox

import React from 'react';

interface IProps extends Omit<React.InputHTMLAttributes<HTMLInputElement>, 'onChange'> {
  onChange(value: boolean): void;
}

export const Checkbox: React.FunctionComponent<IProps> = ({ children, 
onChange, ...shared }) => {
  return <input onChange={e => onChange(e.target.checked)} {...shared} />
}

Checkbox.defaultProps = {
  type: 'checkbox',  
}

Now you can use it like here:

<Checkbox checked={false} onChange={toggleCheckbox} />

It is end of small tutorial. If it will be helpful for someone, I can continue to explain some good things of React and Typescript. Thanks for attention.

Linguistic accessibility. Internationalize your React applications.

Maksim — Mon, 25 Mar 2019 09:45:21 +0000

Internationalization is the process of adapting an application to work with different languages and regions.

That can bring some benefits. Your target group can be broader than the one with the default language of the app. So by internationalizing an app, you may reach a bigger audience.

Cultural accessibility. Internationalization it's not only about translation text. Users expect localized Dates, Number separators, Currencies. Even colors can have various meaning across different cultures. While in Western cultures the color green can symbolize environmental friendliness, in Iran it evokes joy, while in China it symbolizes disgrace.

eo-locale

I want to talk you about small, but pretty useful library. It provide you easy way to format numeric, dates and manage your translations. If you don't want read whole article, just see code.

The first that you need, add library in your project.
yarn add eo-locale or npm i eo-locale --save

And... that's it, now you can format values.

Currencies

Many countries that use the same currency have slightly different formats when displaying prices. The days of setting one price in U.S. dollars, pounds or euros and then forcing customers to adapt are long over. EOLocale.Number - component for format numeric values. Support for 150+ languages.

import { EOLocale } from 'eo-locale';

<EOLocale.Number
  value={1000}
  currency="EUR"
  maximumFractionDigits={2}
  minimumFractionDigits={2}
  style="currency"
/>
// €1,000.00

Dates

The legal and cultural expectations for date and time representation vary between countries, and it is important to be aware of the forms of all-numeric calendar dates used in a particular country to know what date is intended. EOLocale.Date - component for format date values.

import { EOLocale } from 'eo-locale';

<EOLocale.Date
  value={new Date(2019, 2, 19)}
  day="numeric"
  month="long"
  year="numeric"
  weekday="long"
 />
 // Tuesday, March 19, 2019

Texts

Online shoppers prefer to do business in their native tongue. 42% of Europeans have reported to only shop online in their native language. Another report found that 72% of online shoppers who are not native English speakers would like the product reviews to be available in their native languages.

If you want manage your translations, need little bit more work. Add EOLocale.Provider in root of your application. eo-locale based on new React.Context api.

import { EOLocale } from 'eo-locale';

const locales = [
  {
    language: 'en',
    messages: {
      hello: 'Hello {name}!'
    }
  },
];

<EOLocale.Provider language="en" locales={locales}>
  <span>
    <EOLocale.Text id="hello" name="World" /> // Hello World!
  </span>
</EOLocale.Provider>

You can pass prop with any name in EOLocale.Text component. Pluralization supported also.

import { EOLocale } from 'eo-locale';

const locales = [
  {
    language: 'en',
    messages: {
      items: '{count, plural, one {One item} other {{count} items}}'
    }
  },
];

<EOLocale.Text id="items" count={3} />
// 3 items

If you need do some logic with strings, just import use Translator hook.

import { useTranslator } from 'eo-locale';

function SomeComponent() {
  const translator = useTranslator();

  return <div>{translator.formatNumber(1000)}</div>;
}

You can format html values also. More examples on GitHub page. All of this things based on Internationalization API, which very good supported nowadays. Server side rendering supported also. I hope, that this library will help you in your work. Enjoy!