DEV Community: Georg

Manual Render Invalidation: A Deliberate React Anti-Pattern

Georg — Wed, 28 Oct 2026 12:37:33 +0000

While developing the morphing-scroll library, I arrived at an unusual way of organizing local data inside a React component. It was not an architecture I had designed in advance. I was experimenting with updates, gradually removing unnecessary state, and at some point the code became noticeably simpler than before. For me, it was a genuine discovery.

Later, I extracted the mechanism into a useRerender hook and added it to my state manager, nexus-state. In this article, I want to show not only the result, but also the path that led me to it.

The idea is to separate two operations that useState usually combines:

change the data;
tell React that the UI needs to update.

The data can live in refs and be changed synchronously, while a single shared signal is used to update the UI. This goes against the conventional React model and is not suitable for every component. That is exactly why it is interesting to explore where such an anti-pattern can become a useful tool.

Throughout this article, I will call this approach manual render invalidation. The data changes independently of React, and the developer explicitly signals when the current view should be considered stale and rebuilt. I coined this name for the article; it is not an established React term.

From a Regular Counter to Redundant State

Let us start with a regular counter:

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount((value) => value + 1)}>
      Clicks: {count}
    </button>
  );
}

Here, useState is exactly the right tool. The value is used during rendering, and every change should update the button text. This code is familiar to almost every React developer, and there is nothing unusual about it yet.

Now let us place the counter inside a product card. In addition to quantity, we need a selected product and a total price. We will deliberately write the first version in the most straightforward way: one useState for every changing value.

const products = {
  keyboard: { name: "Keyboard", price: 80 },
  mouse: { name: "Mouse", price: 40 },
  display: { name: "Monitor", price: 350 },
};

function ProductCard() {
  const [productId, setProductId] = useState("keyboard");
  const [quantity, setQuantity] = useState(1);
  const [total, setTotal] = useState(products.keyboard.price);

  function changeProduct(nextProductId) {
    setProductId(nextProductId);
    setTotal(products[nextProductId].price * quantity);
  }

  function changeQuantity(nextQuantity) {
    setQuantity(nextQuantity);
    setTotal(products[productId].price * nextQuantity);
  }

  return (
    <section>
      <select
        value={productId}
        onChange={(event) => changeProduct(event.target.value)}
      >
        <option value="keyboard">Keyboard</option>
        <option value="mouse">Mouse</option>
        <option value="display">Monitor</option>
      </select>

      <button onClick={() => changeQuantity(Math.max(1, quantity - 1))}>
        −
      </button>
      <span>{quantity}</span>
      <button onClick={() => changeQuantity(quantity + 1)}>+</button>

      <p>Total: ${total.toLocaleString("en-US")}</p>
    </section>
  );
}

The code works, but a review reveals an uncomfortable dependency. Every product or quantity change must also call setTotal. If another way to change the quantity appears later, the total can easily fall out of sync with the rest of the data.

total has no independent source. It is always the selected product's price multiplied by the quantity, so there is no reason to store it:

function ProductCard() {
  const [productId, setProductId] = useState("keyboard");
  const [quantity, setQuantity] = useState(1);

  const product = products[productId];
  const total = product.price * quantity;

  // The rest of the markup stays the same
}

This removes setTotal, both manual synchronization points, and the possibility of contradictory state. React also recommends avoiding redundant state.

At first, this looked like an ordinary cleanup: find redundant state, replace it with a calculation, and reduce the number of values that need synchronization. But the refactoring raised a broader question.

If one value does not need to be React state because it can be calculated, where is the actual boundary? Does React have to store the remaining data merely because it sometimes appears in JSX? Can we change it ourselves and ask React to render only when the result is ready to be shown?

In React, it is easy to start associating every change with useState. As a result, new state often appears automatically, before we even ask whether React should own that value.

This is where I began to wonder: what if I removed every useState, stored the data myself, and kept only one shared update mechanism?

The product-card example is deliberately simple. In practice, this approach helped me while developing a complex React component built around scrolling.

The Turning Point in morphing-scroll

morphing-scroll had a different problem. The component manages scrolling, virtualization, dragging, inertia, and its own controls. To do that, it needs:

the current and target scroll positions;
viewport and content dimensions;
the visible item range;
the movement direction;
dragging and animation state;
identifiers of scheduled frames.

The first obvious solution looks like this:

const [scrollTop, setScrollTop] = useState(0);
const [targetScrollTop, setTargetScrollTop] = useState(0);
const [viewportHeight, setViewportHeight] = useState(0);
const [visibleRange, setVisibleRange] = useState([0, 20]);
const [isDragging, setIsDragging] = useState(false);
const [isScrolling, setIsScrolling] = useState(false);

The number of hooks alone does not explain the problem. Complexity appears when there are many state values and relationships emerge between them. A single scroll event changes the position, direction, and visible range. Starting a drag switches several flags. On every frame, the animation needs to read fresh data, calculate the next values, and sometimes update the JSX.

A setter also does not change the value inside the handler that is currently running:

function handleScroll(nextScrollTop) {
  setScrollTop(nextScrollTop);

  console.log(scrollTop); // value from the current render
}

This is how React state works: every render receives its own snapshot, and the setter queues the next one. That is a useful guarantee for a declarative interface. Inside the scrolling algorithm, however, I needed synchronously mutable data that handlers could access immediately. Several independent setters made the order of calculations harder to reason about.

React batches multiple state updates into a single render. But batching only answers how many renders will happen. It does not separate changing the data from requesting a UI update: every setter still does both.

Why Not useReducer?

Related state can be grouped in useReducer. This removes multiple setters, leaves a single dispatch, and is the more conventional solution for most components.

However, a reducer preserves React's underlying model: dispatch queues a new state snapshot and requests a render along with it. I needed something different in morphing-scroll. The internal model had to change synchronously, sometimes several times between frames, while React should only become involved when the accumulated result was ready to be displayed.

The issue was therefore not only the number of setters. I needed to separate changing the data from publishing those changes to the interface.

A Ref as the Component's Internal Model

I grouped the related values into a single object inside useRef:

const runtimeRef = useRef({
  scrollTop: 0,
  targetScrollTop: 0,
  viewportHeight: 0,
  rowHeight: 40,
  visibleRange: [0, 20],
  isDragging: false,
  isScrolling: false,
});

Now the handler can finish every calculation synchronously:

function handleScroll(element) {
  const runtime = runtimeRef.current;

  runtime.scrollTop = element.scrollTop;
  runtime.viewportHeight = element.clientHeight;
  runtime.visibleRange = calculateVisibleRange(
    runtime.scrollTop,
    runtime.viewportHeight,
    runtime.rowHeight,
  );
  runtime.isScrolling = true;
}

Each line immediately sees the result of the previous one. There are no separate setters, and there is no need to remember which render snapshot a value belongs to.

One problem remains: changing ref.current does not trigger a render. React does not know that it should read visibleRange again.

useRerender as a Separate Signal

A function component can request another render through dummy state:

import { useReducer } from "react";

function useRerender() {
  const [, rerender] = useReducer((version) => version + 1, 0);

  return rerender;
}

The version value is never used. Its only purpose is to make React start another render of the component.

Now several changes can end with one explicit rerender:

const rerender = useRerender();

function handleScroll(element) {
  const runtime = runtimeRef.current;

  runtime.scrollTop = element.scrollTop;
  runtime.viewportHeight = element.clientHeight;
  runtime.visibleRange = calculateVisibleRange(
    runtime.scrollTop,
    runtime.viewportHeight,
    runtime.rowHeight,
  );

  rerender(); // explicitly update the UI at the end
}

This was the turning point for me. Until then, I had treated changing data and rendering as one operation: state changed, so React should start an update. It turned out that the two can be separated. First bring the internal model into a consistent state, then publish the result with a single signal.

Change the data first. Then decide when React should display it.

The code unexpectedly became easier to understand. Instead of a large collection of value/setValue pairs, I had a regular object and one shared rerender. I no longer had to remember a separate setter name for every field or the order of several queued updates. Multiple mutations became a single, explicitly marked update boundary.

This, rather than the three lines inside useRerender, was the key result of the experiment. The component became responsible for the timing of the update: it decides which changes should be included in the next render.

This style is much closer to ordinary imperative JavaScript. We change the required data synchronously and involve React only when we want to display its current version in the UI.

One Render per Frame

scroll and pointermove events may fire several times between two browser paints. In that case, the signal can be limited to one call per frame:

const frameRef = useRef(null);
const rerender = useRerender();

function renderInNextFrame() {
  if (frameRef.current !== null) return;

  frameRef.current = requestAnimationFrame(() => {
    frameRef.current = null;
    rerender();
  });
}

function handleScroll(event) {
  const runtime = runtimeRef.current;

  runtime.scrollTop = event.currentTarget.scrollTop;
  runtime.visibleRange = calculateVisibleRange(
    runtime.scrollTop,
    runtime.viewportHeight,
    runtime.rowHeight,
  );

  renderInNextFrame();
}

If five events occur between frames, the ref retains the result of the last one, while React receives only one render request. This is not automatic batching. It is an update boundary defined by the component itself. A scheduled requestAnimationFrame should also be cancelled when the component unmounts.

For morphing-scroll, this became the main advantage: the rate at which the internal data changes no longer has to match React's render rate. It also helped performance because the component did not request more renders than the browser could actually paint.

What Do We Give Up?

React treats refs as an escape hatch. The documentation recommends using them for values that do not participate in JSX and warns against reading ref.current during rendering. Manual invalidation deliberately crosses that boundary: JSX reads data from a ref, and useRerender makes React read it again.

This comes with limitations:

If you forget to call rerender, the data changes but the interface remains stale. React no longer manages that connection for you.
Reading a mutable ref during rendering goes beyond React's standard contract. This code works through explicit invalidation, but the linter and newer React features rely on a different contract: rendering should be determined by props, state, and context.
A stable reference requires extra care with memoization. React.memo, useMemo, and reference equality checks do not notice mutations inside the object. It is safer to pass specific values or a separate update version to child components.
Ref changes do not appear in React DevTools as regular state updates, which makes them harder to trace while debugging.

Effects have an additional caveat. ref.current is not reactive by itself. However, after changing it we call rerender, so during the next render React still compares the new dependency value with the previous one:

useEffect(() => {
  doSomething(runtimeRef.current.scrollTop);
}, [runtimeRef.current.scrollTop]); // reevaluated in the render triggered by rerender()

This works specifically because of useRerender: it starts a render in which the dependency expression is evaluated again, and React compares the result using Object.is. If the ref changes without rerender, the effect never learns about it.

exhaustive-deps may warn that a mutable value is not a valid reactive dependency. A modern eslint-plugin-react-hooks configuration may also enable the refs rule because the dependency is read during rendering. These warnings are correct for conventional React code: mutating a ref does not trigger a render. With manual invalidation, useRerender supplies the missing step, but the linter cannot infer that contract from the code. A local suppression becomes another explicit cost of the anti-pattern.

Such an effect reacts only to values that reach a render, not to every ref mutation. Its callback also reads runtimeRef.current.scrollTop when the effect actually runs, so it may see a newer value than the one React compared in the dependency array. If every mutation or the exact snapshot of a particular update matters, invoke the side effect next to the data change or use a fully reactive source instead.

Rewriting the Product Card with the Anti-Pattern

At the beginning of the article, we removed only the derived total, while productId and quantity remained in React state. For the sake of the experiment, let us take the idea all the way and rewrite the card without a single useState. The products object containing names and prices remains the same one declared outside the component in the first example.

function ProductCard() {
  const rerender = useRerender();

  const modelRef = useRef({
    productId: "keyboard",
    quantity: 1,
  });

  const model = modelRef.current;
  const total = products[model.productId].price * model.quantity;

  return (
    <section>
      <select
        value={model.productId}
        onChange={(event) => {
          model.productId = event.target.value;
          rerender();
        }}
      >
        <option value="keyboard">Keyboard</option>
        <option value="mouse">Mouse</option>
        <option value="display">Monitor</option>
      </select>

      <button
        onClick={() => {
          model.quantity = Math.max(1, model.quantity - 1);
          rerender();
        }}
      >
        −
      </button>

      <span>{model.quantity}</span>

      <button
        onClick={() => {
          model.quantity += 1;
          rerender();
        }}
      >
        +
      </button>

      <p>Total: ${total.toLocaleString("en-US")}</p>
    </section>
  );
}

model.productId stores the key of the selected product, for example "keyboard". The expression products[model.productId] finds the product in the catalog by that key, after which its price is multiplied by the quantity.

total remains a regular constant because it is calculated from the source data during every render. Moving it into another ref would bring no meaningful benefit and would reintroduce the manual synchronization that we removed at the beginning of the article.

The code is straightforward: data changes through regular assignments, and every field shares the same rerender. Before calling it, we can change one field or several at once.

Where Is This Approach Most Useful?

I would consider refs together with useRerender for components that have their own imperative model:

virtualized lists and complex scrolling;
drag and drop;
canvas and WebGL;
animation loops;
high-frequency pointer events;
DOM measurements and synchronization with browser APIs.

The advantage is most noticeable when data changes more often than JSX should update, or when several values need to change consistently before a render. Another reason to consider the approach is a large amount of local state in one component. Every new value/setValue pair adds another name and another update path that must be kept in mind. If that makes the code harder to read and control, one data object and a shared rerender can noticeably reduce the cognitive load.

There is no universal number of useState calls after which a component must be rewritten. What matters is the practical result: which model describes the component more accurately, and which one makes data changes easier to follow.

How Original Is This Technique?

I arrived at this solution independently while working on morphing-scroll. I was not searching for an existing pattern or trying to reproduce someone else's implementation. The idea emerged from experiments with a real component and immediately proved useful in practice. That is why the moment it worked felt like a revelation.

At the same time, the individual parts of the approach existed before. The old React Hooks FAQ demonstrates an almost identical useReducer counter, and various libraries provide hooks named useForceUpdate, useUpdate, or useRerender. The mechanism for forcing a render is not new.

There are also closer architectural parallels. useSyncExternalStore separates an external data source from the signal sent to subscribers. MobX and Valtio let a model change independently of React while automatically tracking which components need to update. In React Three Fiber, imperative changes can be followed by invalidate() to request another frame. The last example is especially close to how this approach works with scrolling and requestAnimationFrame.

However, among the examples I found, I did not see an ordinary local React component described in exactly this way: refs serve as a complete model, while one rerender becomes an explicit publication boundary. Similar code may have been written before, but I am not claiming to have invented the hook. What matters to me is the independently discovered way of organizing the component around it.

The name "manual render invalidation" describes this complete model. If the current data already lives outside React state, there is no reason to present a technical render counter as domain state. Its actual job is to mark the current view as stale and ask React to build a new one.

That is why I added this primitive to nexus-state:

const rerender = nexus.useRerender();

runtimeRef.current.value = nextValue;
rerender();

Conclusion

The path to useRerender did not begin with a desire to invent a new hook. While developing morphing-scroll, working with many related state values became so confusing that I started removing unnecessary useState calls one by one. As a result, most of the runtime data moved into refs, while a separate useRerender hook remained solely as a signal telling React to render the current model.

This experience changed how I think about useState. It is not merely a container with a value/setValue pair, but a contract with React: React stores a snapshot of the data and decides when to show the next one. If a component accumulates so many state variables that navigating their values and setters becomes difficult, that is already a valid reason to consider another model. This is especially true when the values are related, need to change synchronously, or the data changes more often than the interface needs to render. In those cases, a more imperative approach with useRerender may be easier to read and control.

useRerender showed me another model: data can change as a regular JavaScript object, while rendering becomes a separate explicit operation. We can update several values, inspect the result, wait for the next frame if necessary, and only then ask React to update the interface. For complex scrolling, this was not a workaround, but the most direct description of what was happening.

When this version first worked, I was surprised by how little machinery remained in the code. I removed several abstractions and gained more control: one mutable model, one way to request a render, and a clear boundary between calculation and display.

That is the essence of manual render invalidation for me. The main idea is not to replace every useState, but to stop treating data changes and interface updates as one indivisible operation. I hope this path helps other developers look at React from a slightly different angle.

If you would like to see the context from which this approach grew, you can also read my other articles:

How I Wrote My Own State Manager

Georg — Mon, 28 Sep 2026 14:19:29 +0000

I want to devote this article to the different ways of updating data in JS and React, using my own library, "nexus-state", as the running example. I will share detailed examples and my motivation, and explain what state managers are actually for and how they work. In the examples I will try to keep things as simple as possible, and I will not touch on typing.

Introduction

The name came to me out of nowhere. Having finished every game in one of my favourite series, "Dark Souls", I stumbled upon the earlier "Demon's Souls" (which, ironically, I never played) — or more precisely, upon the description of the Nexus. In that game it is a kind of hub where the player can teleport, level up and rest.

I liked the name. It comes from Latin and means "link", "knot", "connection" — and there was an analogy in that: a developer, much like the game's protagonist, walks through the hardships of a project and always has access to the Nexus, where they can get what they need. In development, that something is data. Put simply, it is the connection — the connection to your data.

The name was already taken on npm, so the library became "nexus-state". I will add that I wanted the people using it to keep that same feeling of having something to lean on along the thorny path of development — that connection to data, through "nexus-state".

Prologue

With years of work as a UI/UX designer behind me, a little JS knowledge and some experience writing HTML and CSS, I ran into React some time around 2021. It was the logical next step in my professional growth.

I wrote components, studied hooks and enjoyed myself: it felt like I could now make any UI I could imagine actually work. But the harder the tasks became, the more often I ran into limits.

One of them was working with state. More precisely, the question of how to conveniently update the same data living in different components. That is the first question every so-called global state manager answers.

Let's look at an example. Say we have a game website where the hero's name and class have to appear in several components at once:

function App() {
  return (
    <>
      <Header />
      <Sidebar />
      <Profile />
    </>
  );
}

The useState hook will not help here: it is local only, and we cannot store the same data separately in every component — the copies would drift apart.

In theory we could lift the state up to a common parent and pass the data down through props. But that approach has a price, and it becomes noticeable once there is a lot of data and a lot of components: every change re-renders the entire subtree under the component holding the state, including components that have nothing to do with that data.

Memoization hooks help for a while, but sooner or later this leads to needless complexity. There is also useContext — more on that later, but at the start of my journey it was not what I wanted to use.

And this is where the idea of a global state manager comes in, creating a shared Store we can always read current data from, data that triggers a re-render by itself once it changes.

                   Store
                     │
        ┌────────────┼────────────┐
        ↓            ↓            ↓
      Header       Sidebar      Profile

There is no shortage of ready-made solutions. But I was only beginning to find my way around the frontend, and the most important part bothered me: when I used them, I did not understand what was happening inside. Everything works — but how exactly, nobody knows. From the outside it looks like magic.

And then I came across an article about Flux, which introduced me to the notions of "publisher/subscriber". I fell in love with that architecture and started using it.

A Sense of Control

Flux removed all the magic, making the flow of data completely transparent. Here is a simple example of a store built on the Flux architecture, without a Dispatcher for now — we will come back to it later.

// myStore.js
// our default data
let state = {
  name: "Duncan",
  role: "knight",
};

const listeners = new Set(); // a collection of listeners

export const store = {
  // read the data
  getState() {
    return state;
  },

  // write the data
  setState(newState) {
    state = {
      ...state,
      ...newState,
    };

    // walk every subscriber and tell them something changed
    listeners.forEach((listener) => listener());
  },

  // subscribe to updates
  subscribe(listener) {
    listeners.add(listener);

    return () => listeners.delete(listener); // hand back a way to unsubscribe
  },
};

So we now have methods for reading and updating data, used like this:

import { store } from "./myStore";

console.log("state -", store.getState()); // print the data

// we get state - { name: "Duncan", role: "knight" }

Right now Flux has no idea React exists. The store can hold state and notify subscribers when it changes, but on its own it cannot make React re-render anything. Let's write a small React hook for that.

// useStore.js
import { useSyncExternalStore } from "react";
import { store } from "./myStore";

export function useStore() {
  return useSyncExternalStore(store.subscribe, store.getState);
}

For this example I used React's built-in useSyncExternalStore hook, which lets you subscribe a component to an external source of state — our Flux store, in this case. When the store reports a change, React reads the current state and re-renders the component if needed.

But useSyncExternalStore is not part of Flux here. It is merely the link between the Flux store and React.

To get a better feel for how that link works, let's try writing our own useStore using simpler React hooks — useEffect and useState.

// useStore.js
import { useEffect, useState } from "react";
import { store } from "./myStore";

export function useStore() {
  const [state, setState] = useState(store.getState);

  useEffect(() => {
    return store.subscribe(() => {
      setState(store.getState());
    });
  }, []);

  return state;
}

Something fairly simple happens here: when the component is created, we subscribe to the store. When the store changes, its subscribe calls our callback, and the callback passes the new state into setState. Changing local state makes React re-render, and the hook returns the store's current state. That is exactly what useSyncExternalStore does.

Note useState(store.getState): the function is passed without being called — it is a lazy initializer. React will call it once on the first render and put the result into state, rather than the function itself.

Flux itself still knows nothing about React. It only provides two mechanisms: read the state (getState) and subscribe to its changes (subscribe). Everything that happens after that is the React integration's job.

So we already have a working solution for managing data without losing control at any step. We can update data now, but the current implementation has a problem: store.setState merges any keys you hand it into the state, and there is no way to tell from the code which updates are even intended. This is where it is worth extending the architecture with the Dispatcher concept, narrowing updates down to a known dictionary of actions.

// dispatcher.js
const handlers = new Set(); // action handlers

// create the dispatcher
export const dispatcher = {
  register(handler) {
    handlers.add(handler);

    return () => handlers.delete(handler);
  },

  // notify is passed along so the handler decides when to announce the change
  dispatch(action, notify) {
    handlers.forEach((handler) => handler(action, notify));
  },
};

Now let's add the dispatcher to our Flux:

// myStore.js
import { dispatcher } from "./dispatcher";

let state = {
  name: "Duncan",
  role: "knight",
};

const listeners = new Set();

// the supported updates are registered here — because this is where state lives
dispatcher.register((action, notify) => {
  switch (action.type) {
    case "HERO_SET_NAME":
      state = {
        ...state,
        name: action.payload,
      };
      break;

    case "HERO_SET_ROLE":
      state = {
        ...state,
        role: action.payload,
      };
      break;

    // an unknown action changes nothing and wakes nobody
    default:
      return;
  }

  notify(); // this calls the function that updates the subscribers
});

export const store = {
  getState() {
    return state;
  },

  // send an action
  dispatch(action) {
    // pass a function, not a call: the handler runs it after the change
    dispatcher.dispatch(action, () => {
      listeners.forEach((listener) => listener());
    });
  },

  subscribe(listener) {
    listeners.add(listener);

    return () => listeners.delete(listener);
  },
};

Notice too that the store's method is now called dispatch rather than setState: it takes an action, not a slice of state, and the old name would only be confusing.

Updates are now described by two parameters: type says what we are changing, and payload carries the new data.

import { store } from "./myStore";

store.dispatch({
  type: "HERO_SET_NAME",
  payload: "Artorias",
});

That is how I used this architecture, quite happily. Two small files, myStore.js and dispatcher.js, holding the entire one-way data flow, without a single line I did not know the purpose of.

Attempting a Library: Flux + createContext

I kept using Flux, but over time it grew, and I felt like trying to write my own npm library. I had never done it before, but it was a challenge I wanted to take on: by the end I might have something that could serve as an alternative to the managers we have now. And it was simply interesting.

So I started — rather clumsily at first — moving all the logic into a more convenient shape. In the earliest versions I decided to step away from the familiar Flux approach and try combining its capabilities with React: createContext and a provider component.

Let me start with a simple createContext example, one you have probably seen or written yourself:

// MyProvider.js
import { createContext, useState } from "react";

const MyContext = createContext(null);

function MyProvider({ children }) {
  const [hero, setHero] = useState({
    name: "Duncan",
    role: "knight",
  });

  return (
    <MyContext.Provider value={{ hero, setHero }}>
      {children}
    </MyContext.Provider>
  );
}

This lets you keep data inside the context and reach it directly from any child component:

function App() {
  return (
    <MyProvider>
      <Header />
      <Sidebar />
      <Profile />
    </MyProvider>
  );
}

// Profile.js
import { useContext } from "react";

function Profile() {
  const { hero, setHero } = useContext(MyContext);

  return (
    <>
      <h1>Hello, {hero.name}</h1>

      <button onClick={() => setHero({ name: "Artorias", role: "knight" })}>
        Change name
      </button>
    </>
  );
}

It all works — the data travels deep into the tree, which is precisely what context was made for. But that does not make it a state manager, and here is the main reason.

Context re-renders every consumer on any change. React cannot subscribe to a part of a value: it compares value as a whole. If a component called useContext, it re-renders on every context update — even if it reads a single field from there that did not change.

What is more, in our example value={{ hero, setHero }} is a new object on every render of the provider. Which means the re-render goes out to every consumer always, whether hero changed or not.

And memo does not save you here: it compares props, while useContext reads its value bypassing props entirely. A component wrapped in memo still re-renders if the context it reads was updated.

The usual workaround is slicing the data across several contexts so components subscribe to different ones. That works while you have two or three; beyond that it turns into a tree of providers where every little thing gets one more.

So we are left with exactly the problems we already solved in our own Flux implementation: reading state independently of a component, subscribing only to the part you need, and changing it through a single interface. Let's now try to combine Flux and useContext:

// MyProvider.js
import { useRef } from "react";

let state = {
  name: "Duncan",
  role: "knight",
};

function MyProvider({ children }) {
  const subscribers = useRef(new Set());

  const setState = (newState) => {
    state = {
      ...state,
      ...newState,
    };

    subscribers.current.forEach((callback) => callback());
  };

  return (
    <MyContext.Provider
      value={{
        getState: () => state,
        setState,
        subscribe: (callback) => {
          subscribers.current.add(callback);

          return () => subscribers.current.delete(callback);
        },
      }}
    >
      {children}
    </MyContext.Provider>
  );
}

It plugs in the same way as the ordinary provider above.

Although the initial data is still hardcoded into the module — how a user of the library would supply their own is unclear. Let's keep that question in mind; we will come back to it soon.

But from here on the difference begins. Components no longer read data straight out of the context — the context only holds getState, setState and subscribe, that is, the store's interface rather than the state itself. A component receives data through a subscription. Let's build the useStore hook again with useSyncExternalStore, but taking what it needs from the context:

// useStore.js
import { useContext, useSyncExternalStore } from "react";

export function useStore() {
  const { getState, subscribe } = useContext(MyContext);

  return useSyncExternalStore(subscribe, getState);
}

And the long-awaited usage:

// Profile.js
import { useContext } from "react";
import { useStore } from "./useStore";

function Profile() {
  const { name } = useStore(); // a reactive variable
  const { setState } = useContext(MyContext); // a way to change the data

  return (
    <>
      <h1>Hello, {name}</h1>

      <button onClick={() => setState({ name: "Artorias" })}>
        Change name
      </button>
    </>
  );
}

The context value no longer changes when the data is updated — what changes is the state next to it, and components learn about it through subscribe. That problem of re-rendering every consumer is gone. And this is already a decent implementation that works.

Where This Construction Falls Apart

It looks functional. But take a close look at where things live:

let state = { ... };                      // outside the component

function MyProvider({ children }) {
  const subscribers = useRef(new Set());  // inside the component

state is declared at module level: there is a single one for the whole application, and it lives as long as the provider does. subscribers is created with useRef: each instance of MyProvider gets its own, and it dies along with that instance.

While there is a single provider this goes unnoticed, but mount two:

<MyProvider>
  <Profile />    {/* one set of subscribers */}
</MyProvider>

<MyProvider>
  <Sidebar />    {/* a different set of subscribers */}
</MyProvider>

Both see the same data — state is shared. But a setState called inside the first provider will only wake its own subscribers. The Sidebar in the second one never hears about the change and stays on screen with stale data.

The mistake is not in either half. The mistake is that the two halves of one store live in different places with different lifetimes. A store is not "data" plus "subscribers" on the side. A store is data together with the subscribers to it. They have to be born together and die together.

There is a second side to the same problem, less visible: the object in value is recreated on every render of the provider, which means subscribe is a new function every time, and useSyncExternalStore is forced to unsubscribe and subscribe again.

Moving the State Inside

The fix suggests itself: since the subscribers live inside the provider, let the state live there too. That also answers the question I have been dodging — how does a user of the library supply their own initial data? Through a prop:

// MyProvider.js
import { useRef } from "react";

function MyProvider({ children, initialState }) {
  const stateRef = useRef(initialState);
  const subscribers = useRef(new Set());

  const setState = (newState) => {
    stateRef.current = {
      ...stateRef.current,
      ...newState,
    };

    subscribers.current.forEach((callback) => callback());
  };

  return (
    <MyContext.Provider
      value={{
        getState: () => stateRef.current,
        setState,
        subscribe: (callback) => {
          subscribers.current.add(callback);

          return () => subscribers.current.delete(callback);
        },
      }}
    >
      {children}
    </MyContext.Provider>
  );
}

There is one subtlety that matters here. You cannot simply reassign the parameter:

function MyProvider({ children, state }) {
  const setState = (newState) => {
    state = { ...state, ...newState }; // the edit lives until the next render
  };

React calls the component again on every render, and the parameter is read afresh from props — everything we wrote into it disappears. We need a place that survives renders, and that is useRef.

Now everything is honest: we pass our own data in from outside, and the provider has become independent.

const state = {
  name: "Duncan",
  role: "knight",
};

<MyProvider initialState={state}>
  <Profile />
</MyProvider>;

This approach is what I built my first two versions of the library on.

Moving to Factories

It works. But look at what we ended up with: the entire store lives inside a React component.

You cannot create it without React — you need a renderer. You cannot check it in a test without mounting a component tree. You cannot use it in an event handler outside React, in a worker, or on the server. The lifetime of the data is tied to the lifetime of a piece of interface, even though the data has nothing to do with the interface.

And the problem of the object in value being recreated on every render has not gone anywhere either.

Yet the only piece of React we actually need here is useRef, so that something survives a render. But if the store does not live inside a component, there is nothing to survive: a plain variable in a closure already lives exactly as long as we need.

Let's move everything out of the component into an ordinary function:

function createStore(initial) {
  let state = initial;
  const listeners = new Set();

  return {
    getState: () => state,

    setState: (next) => {
      state = { ...state, ...next };
      listeners.forEach((listener) => listener());
    },

    subscribe: (listener) => {
      listeners.add(listener);

      return () => listeners.delete(listener);
    },
  };
}

A function like this is called a factory. This way of writing code is described well in the book "Learning JavaScript Design Patterns", which — ironically — I came across later than I ran into the concept itself. Everything becomes simple: call it, get a store. Its own state, its own subscribers, a stable reference to an object that does not change from render to render. Need a second, independent one? Call it again. It is a little reminiscent of Flux, except now it feels reusable.

And this is where I eventually arrived.

What the Closure Buys Us

The factory above solves the lifetime problem, but so far it does exactly what the old store did. What it has now, though, is a place to put everything else: state and listeners are just variables inside a function call, and you can declare as many others next to them as you like.

Let's start with the thing this was all about. Remember the complaint about lifting state up — the whole subtree re-renders, including the components that are not involved? Our store still behaves the same way: listeners is a single set, and setState wakes absolutely every subscriber, even if only one field changed.

To wake only the right ones, the set of subscribers has to be laid out by key:

function createStore(initial) {
  let state = initial;
  const listeners = new Map(); // key -> the set of subscribers to it

  const notify = (keys) => {
    // first gather who to call: a subscriber watching several keys
    // should get one notification, not one per key
    const called = new Set();

    keys.forEach((key) => {
      listeners.get(key)?.forEach((listener) => called.add(listener));
    });
    listeners.get("*")?.forEach((listener) => called.add(listener));

    called.forEach((listener) => listener(state));
  };

  const get = (key) => (key === undefined ? state : state[key]);

  const set = (next) => {
    const prev = state;
    state = { ...state, ...next };

    // notify only for the keys that actually changed
    const changed = Object.keys(next).filter((key) => prev[key] !== state[key]);
    if (changed.length) notify(changed);
  };

  const subscribe = (listener, keys = ["*"]) => {
    keys.forEach((key) => {
      if (!listeners.has(key)) listeners.set(key, new Set());
      listeners.get(key).add(listener);
    });

    return () => keys.forEach((key) => listeners.get(key)?.delete(listener));
  };

  return { get, set, subscribe };
}

Not much changed — Set became Map — but the behaviour is now different:

const store = createStore({ name: "Duncan", role: "knight", level: 3 });

store.subscribe(onName, ["name"]);
store.subscribe(onLevel, ["level"]);

store.set({ name: "Artorias" }); // onName was called, onLevel was not
store.set({ name: "Artorias" }); // same value: nobody was called

Three things at once. A component reading level will not re-render when the name changes: the experience bar does not flicker because the player renamed their hero. Writing the same value wakes nobody at all. And a subscriber watching both name and level gets one notification when both keys update rather than two — which is exactly why notify builds that intermediate called set.

Actions Live There Too

The second thing that was missing. Remember the dispatcher? It worked, but it lived apart from the store and knew about state through a module-level variable — the very scope problem we are curing here.

Since a factory is a function, we can hand it not only the initial state but also a description of the actions. And it will call that description, passing get and set inside:

function createStore({ state: initial, acts }) {
  let state = initial;
  const listeners = new Map();

  // ... notify, get, set, subscribe — as above ...

  // actions are born right here and receive get/set through the closure
  const actions = acts ? acts(get, set) : {};

  return { get, set, subscribe, acts: actions };
}

This is pleasant to use: nothing has to be wired up by hand, an action already knows its store. And so we arrive at the final implementation:

const store = createStore({
  state: { level: 1 },

  acts: (get, set) => ({
    levelUp() {
      set({ level: get("level") + 1 });
    },

    boost(n) {
      set({ level: get("level") + n });
    },
  }),
});

store.acts.levelUp();
store.acts.boost(10);

store.get("level"); // 12

Compare that with the dispatcher: there we had an action object, a switch over a string type, and a separate file that somehow had to reach the state. Here they are ordinary functions, and the state is available to them by virtue of where they were born.

And notice what we did not write. No registration, no list of types, no wiring between files. Everything the store needs is created in a single call and stays inside.

createNexus

Now let's get right up to the library itself. Everything we have written so far is a simplified, if detailed, retelling of what happens inside it. The factory there is called createNexus, and using it looks almost exactly like our last example:

import { createNexus } from "nexus-state";

const nexus = createNexus({
  state: { level: 1 },

  acts: (get, set) => ({
    levelUp() {
      set({ level: get("level") + 1 });
    },
  }),
});

nexus.acts.levelUp();
nexus.get("level"); // 2

What the Factory Returns

The call hands back six things — and all of them are closures over one and the same call, exactly as in our teaching version:

const { get, set, subscribe, reset, middleware, acts } = nexus;

get — read the whole state or a single key.

nexus.get(); // { level: 2 }
nexus.get("level"); // 2

set — write part of the state, either as an object or as a function of the current one. A second argument lets you name the source of the update; more on that shortly.

nexus.set({ level: 5 });
nexus.set((state) => ({ level: state.level + 1 }));

subscribe — subscribe to changes of the chosen keys. Returns an unsubscribe function. The keys are given explicitly, and ["*"] means "all of them".

const off = nexus.subscribe((state) => render(state), ["level"]);

reset — return the state to its initial value: entirely or key by key.

nexus.reset("level"); // the level only
nexus.reset(); // the whole state

middleware — wedge yourself between "I want to update" and "it updated". It sees the previous and the next state along with the source. It too returns a function that removes it.

const stop = nexus.middleware((prev, next, context) => {
  console.log(context?.source, prev.level, "=>", next.level);
});

acts — your actions, the ones from the config.

nexus.acts.levelUp();

What Lies Inside

So far we have been looking at the library from the outside. Let's peek under the hood — this is no longer the API but how it is built: those same variables in a closure, only now there are more of them than in our teaching factory.

function createNexus(options) {
  const frozenInitial = snapshot(options.state); // an untouched copy for reset
  let state = snapshot(options.state); // the live state

  const listeners = new Map(); // subscribers by key
  const localMiddleware = []; // update interceptors

  let batchDepth = 0; // how deeply actions are nested
  const pendingKeys = new Set(); // what piled up during a batch
  let currentActionName; // which action is running right now

  // ...
}

Every line here is an answer to some need, and each is possible only because the store has a space of its own.

frozenInitial — so reset returns to the initial state rather than whatever happened to be left over. localMiddleware — so there is somewhere to keep the interceptors. batchDepth together with pendingKeys — so that an action making five set calls in a row wakes the subscribers once instead of five times.

That last one deserves a word. Actions in createNexus are wrapped: while an action runs, the counter is raised, the changes pile up, and a single notification goes out at the end. That is also where currentActionName comes from: an update made inside an action is automatically tagged with that action's name.

And this is where the thing that sets nexus-state apart shows up.

Where the Update Came From

Every update can have a source, and the store remembers it:

nexus.set({ hero }, "server");
// the extended form, with metadata
nexus.set({ theme }, { source: "storage", meta: { restoredAt: Date.now() } });

An explicitly given source reaches both the subscribers and the middleware:

nexus.subscribe(
  (state, context) => {
    console.log("changed by", context?.source);
  },
  ["hero"],
);

It sounds like a trifle until you hit a task where you cannot do without it.

The classic one is persisting state. The store writes data to localStorage on change and reads it back at startup. But reading is also a set, which means the subscriber that does the writing fires and immediately writes back what it has just read. An echo. People usually fight it with flags like isHydrating, which you must remember to raise and lower.

That brings us to persist. If an update has an origin, no flag is needed: persist simply does not react to what came from itself. From the outside it looks like this:

import { createNexus, persist } from "nexus-state";

const nexus = createNexus({
  state: { name: "Duncan", role: "knight", level: 1 },
});

// persist the name and the class only; let the level live in memory alone
persist(nexus, { key: "hero", include: ["name", "role"] });

One line — and the state survives a page reload. No flags, no checks needed.

persist itself is built on an ordinary subscription — it simply looks at where an update came from. And for the cases where you need to step in before the write, localMiddleware sits in the closure. Middleware is a function called between "I want to update" and "it updated", and it sees both states along with the source:

const stop = nexus.middleware((prev, next, context) => {
  console.log(context?.source, prev.level, "=>", next.level);
});

nexus.set({ level: 10 }, "server"); // server 1 => 10

stop(); // middleware can be removed

If it returns a state, that state replaces the one that was about to be written — and by returning prev you can cancel the update altogether.

The adapter for Redux DevTools is built just as simply, on a subscription: the panel shows not a faceless SET_STATE but the name of the action, because that name was set automatically — by that currentActionName from the factory's closure.

import { devtools } from "nexus-state/devtools";

devtools(nexus, { name: "hero" });

Back to React

The core is ready — and, like Flux at the very beginning, it knows nothing about React. But this article started with a React problem, and it is time to close it.

The hooks live behind a separate entry point:

import { createReactNexus } from "nexus-state/react";

const nexus = createReactNexus({
  state: { name: "Duncan", role: "knight" },

  acts: (get, set) => ({
    rename(name) {
      set({ name });
    },
  }),
});

createReactNexus is the same factory. Inside, it calls createNexus and adds three hooks to the result, closed over that same store:

return {
  ...nexus, // everything createNexus returns
  use,
  useSelector,
  useRerender,
};

So it has everything the core had — get, set, subscribe, reset, acts, middleware — plus the React part.

And now the very example we started with:

function Header() {
  const name = nexus.use("name");

  return <h1>Hello, {name}</h1>;
}

function Sidebar() {
  const name = nexus.use("name");

  return <aside>{name}</aside>;
}

function Profile() {
  return (
    <button onClick={() => nexus.acts.rename("Artorias")}>Change name</button>
  );
}

function App() {
  return (
    <>
      <Header />
      <Sidebar />
      <Profile />
    </>
  );
}

Notice what is missing here. There is no provider. The tree is not wrapped in anything: the store exists on its own, and components subscribe to it directly. Nothing has to be lifted up or threaded down through props.

And Profile, which does not read the name, will not re-render when it changes — it is simply not subscribed to anything. use("name") is a subscription to exactly one key, that same Map from the section about closures.

When you need something derived from the state rather than a field, there is useSelector:

function Greeting() {
  const fullName = nexus.useSelector((state) => `${state.name} ${state.role}`);

  return <span>{fullName}</span>;
}

The keys the selector reads are tracked automatically — there is no dependency list to pass.

Why It Is a Separate Import

createNexus lives in nexus-state, and createReactNexus in nexus-state/react. The split is not cosmetic.

The core does not import React at all: the package has zero dependencies, and createNexus works in any environment — in Node, in a worker, in a test without a renderer. React is declared as an optional peer and is only needed by those who reach for the second entry point.

This is exactly the thought everything started with — "Flux does not know React exists" — only carried all the way into how the package is built. The React hooks are not part of the store here but a layer on top: createReactNexus calls createNexus and adds three functions that are aware of React.

The circle is closed. That task from the prologue — showing a single name in three components — is solved in three lines, and I know what happens in every one of them.

What Did Not Make It In

The library ships createActs, which lets you spread actions across files without losing either the types or access to one another. There are recipes for Immer and for SSR in Next.js.

And separately, the types. I promised not to touch typing and I did not, but I will say one thing: state and actions are inferred from the config, so you hardly ever write generics by hand. get("level") returns a number, not any, because the library already knows the shape of your state. Deep typing is one of the things that make this library genuinely pleasant to use.

Also, while writing this article I got curious about checking myself against actual numbers. The closest thing by construction is zustand: the same observer, the same idea of selectors. So that is what I compared against, version 5.0.15.

100 components over 50 keys, 20 updates — each changing a single key

                   selector runs     renders
  zustand 5.0.15            2120          40
  nexus-state                200          40

The render counts are equal — and that matters: zustand does not re-render anything extra, it computes extra. The selector runs for every subscriber, and comparing the result is what cuts off the render. A per-key subscription simply never reaches those who are not involved.

But it has a price, and on small stores it does not pay for itself:

20,000 updates, subscribers without React

   keys    components     zustand   nexus-state
      1             1      3.5 ms        5.2 ms   zustand faster ×1.5
      3             5      3.4 ms        4.6 ms   zustand faster ×1.4
      5            10      4.6 ms        4.8 ms   a tie
     10            20      6.3 ms        5.0 ms   nexus faster ×1.3
     50           100     32.3 ms        8.5 ms   nexus faster ×3.8
    100           500    155.3 ms       13.1 ms   nexus faster ×11.9

The turning point is somewhere around ten keys. Below that, laying subscribers out by key costs more than walking a short list in full.

Conclusion

The main thing I took away: there was no magic. Everything that seemed unfathomable to me in other people's state managers fits into a few dozen lines — a variable, a collection of subscribers, and a function that calls them. The rest is detail, each piece solving a concrete, understandable problem. Though I will admit that writing a library was far from easy and took a good deal of time.

I will add this as well: naming things matters more than the number of features. The most valuable part of nexus-state is not its features but the fact that every update has a source. That single decision removed an entire class of problems that are usually plugged with flags.

When I set out to write the library, what I wanted above all was to understand how state managers work. I hope this article managed to show that.

The library is on npm, the sources are on GitHub. There are also docs to read.

If you have read this far — thank you, and may your Nexus always be within reach.

The story of morphing-scroll, my npm library

Georg — Sat, 19 Sep 2026 19:20:25 +0000

I want to tell you about my npm library — my second npm project, and the most complex one I've built so far. I won't dig deep into the code: this is the story of how and why it came to be.

Introduction

Around 2015 I landed my first job as a UI/UX designer. I drew interfaces for mobile and desktop apps in Sketch, which everyone used back then, on a Mac the company gave me, and I was genuinely happy about it. Things went well: I followed the iOS and Android guidelines, and whenever an app idea resonated with me, I tried to give the design a little extra — filling the interface with my own illustrations (I'm an artist by training) and unusual takes on individual elements. Sometimes it turned out pretty well.

But there was one element whose changes never made it through — the scrollbar. The developers I handed my mockups to really didn't like it when I touched it, and they said so plainly. The scrollbar, and its thumb in particular, was a dark forest you'd better not wander into. And every time I heard "that can't be done", I felt like that guy happily drawing little clouds on buttons to pop music while the developer suffers, trying to carry the artistic vision over into code. That's exactly where a UI mockup and the final product go their separate ways.

Growing into code

Time went by, and bit by bit I started not only drawing mockups but also building them in React. I sank deeper and deeper into development — until one day I came face to face with my old enemy: the browser scrollbar. That's when I felt firsthand the damage thousands of developers had taken, smashing designers' work against the rocks of the impossible.

So what's wrong with it, and which limitations am I talking about? Let's talk about the very curses that doom innocent developers to suffering.

Curse one — "The Tower of Babel"

Long ago everyone spoke one language, everyone understood each other, and nobody had heard of cross-platform woes. Then browser makers, with no single specification or standard, started doing the same thing in different ways. As a result, the same element looks slightly different depending on what you opened the page in.

Curse two — "Deprivation"

This element barely lends itself to customization, and what little there is hardly counts as change: a color via CSS and three width options. There's also ::-webkit-scrollbar, but that's just a paint job: you simply can't put your own element in place of the thumb — one with animation, or one that reacts to movement. All a designer is left with is a sense of helplessness. Strange, isn't it? An element users see on every page, and you can barely style it.

Throwing down the gauntlet

And so, armed with JS and React, in 2023 I decided to take on these plagues. I didn't fully realize how long and thorny the road ahead would be, but the prize was worth it: somewhere in the distance I could see that dream UI where, instead of a dull grey thumb, you can put your own — any shape and style, glowing on hover, growing when pressed, whatever you like. Even a fireball instead of a thumb — I have to be able to do that. Why all these limits?!

The fight

The goal was clear, but I had no way to reach it yet. I wanted the library to work right out of the box. With what I knew, I could write a React component, and that was a decent start, but styling was still an open question: the default styles had to ship with the component. I could have rendered a <style> tag into the HTML on mount, but that's unreliable, so the styles had to live inside the component — and the answer turned out to be as simple as it gets: inline styles. I'm not a fan of inline styles, but here they solved a whole layer of problems in one go: the styling was always in place, exactly where it was needed. It forced me to think the scrollbar's parts through carefully and to answer implementation questions along the way. It was also clear that I wouldn't manage without TypeScript: at some point I simply wouldn't be able to maintain the project. Well then, the stack is set — let's build.

Round one — "The Mix"

In the first version I tried to put together a strange mix: the browser's own scrolling with its thumb hidden and my element in its place. It could only scroll vertically and horizontally — and the horizontal one was really just a rotated vertical one. Very quickly I hit a wall of limitations and realized I'd have to write everything myself — both the scroll event handling and the motion animation. On top of that, I needed scrolling along both axes at once. It became clear that this implementation wasn't serious and looked more like first steps to find my direction. I already knew what to do next, but I was a bit burned out, so I took a break to think it all over and come back with fresh energy.

Round two — "All by myself"

When I sat down to write the second version, I had a much better idea of what the library should do and what it would take. I dug deeper into development and into building the internal mechanics, and things started to work out. But the longer I worked, the more ideas came to me, and the "what else could it do" list grew impressively long. For example, I realized that what I'd written could easily turn the component into a slider as well as a scroll — so I added that mode, and with it arrows and a separate page-turn animation. And from my experience with lists I knew it needed both lazy rendering (an object appears once you scroll to it, and stays) and virtualization (only what's visible lives in the DOM).

At some point the hardest part wasn't having the mechanics, but getting them to live together.

A simple example. A page has a horizontal strip of cards, and the page itself scrolls vertically. A user puts a finger on the strip and moves it — whose gesture is it? If the finger goes sideways, it belongs to the strip; if it goes down, to the page, and that has to be decided within the first few pixels of movement, before the person notices anything. And what if they're dragging the strip's thumb instead of the cards? Then the gesture belongs to the strip alone, and the page must not move a single pixel. Each rule on its own is simple, but the mouse, the finger, the wheel, the keyboard, nested scrolls and sliders start arguing with each other — and most of my time went into settling those arguments.

All of this was driving me crazy and called for an enormous number of checks and tests. Every time I decided I'd done everything I could, I'd come up with something cool I immediately wanted to add — and that started to get on my nerves. That's how the library grew, and the API stopped being coherent. I burned out again and took a break.

Round three — "Order"

Getting started on the third version was hard: a lot had piled up, but I had to put things in order and rework the API. This is where I brought AI into the development, so as not to miss anything during the rework and to cover the code with tests — otherwise, fixing one thing, I'd inevitably break another. And at last a final API I was happy with dawned on the horizon, and the tests were done. A few new features made it in, too: a tile layout of differently sized items, infinite scrolling, and a list that starts on the right — for languages that read right to left.

I'll add that the name wasn't chosen by chance: the component can behave in completely different ways and not even look like a scroll at all — it's all up to your imagination.

At the time of writing, the library is on its third version, and the API is stable.

Wrapping up

It all worked out, but along the way the library made me answer a lot of questions about how a scroll should behave and what it should be able to do.

Reading this, you might wonder: why go to all this trouble over a single element, and who needs it? Use the library if you want to build something unusual rather than what the browser gives you by default. It'll also come in handy for game developers — there are hardly any standard solutions there.

One more thing from me: if you've ever been scared of an evil dragon you didn't feel qualified enough to face, but that keeps getting in your way — try challenging it the next time you meet. At the very least you'll gain new knowledge and skills. At best, you'll make the world a little friendlier, or just more interesting.

I'd also like to thank my colleagues for their patience while I was rolling this library out in production.

You can read the docs, and build your own scroll on morphing-scroll page.

Good luck, and happy coding!

P.S. And here's that very fireball instead of a thumb.

DEV Community: Georg

Manual Render Invalidation: A Deliberate React Anti-Pattern

From a Regular Counter to Redundant State

The Turning Point in morphing-scroll

Why Not useReducer?

A Ref as the Component's Internal Model

useRerender as a Separate Signal

One Render per Frame

What Do We Give Up?

Rewriting the Product Card with the Anti-Pattern

Where Is This Approach Most Useful?

How Original Is This Technique?

Conclusion

Related Articles

How I Wrote My Own State Manager

Introduction

Prologue

A Sense of Control

Attempting a Library: Flux + createContext

Where This Construction Falls Apart

Moving the State Inside

Moving to Factories

What the Closure Buys Us

Actions Live There Too

createNexus

What the Factory Returns

What Lies Inside

Where the Update Came From

Back to React

Why It Is a Separate Import

What Did Not Make It In

Conclusion

The story of morphing-scroll, my npm library

Introduction

Growing into code

Curse one — "The Tower of Babel"

Curse two — "Deprivation"

Throwing down the gauntlet

The fight

Round one — "The Mix"

Round two — "All by myself"

Round three — "Order"

Wrapping up