Forem: Andreas Riedmüller

npm Classic Tokens Are Gone: Two Low-Maintenance Ways to Keep Publishing

Andreas Riedmüller — Tue, 20 Jan 2026 09:49:57 +0000

npm recently announced that classic npm tokens are being deprecated and revoked. Everyone has to migrate to granular tokens, which come with an expiration date (and for publish/write use cases, that effectively means regular rotation).

And, strangely, in the UI there isn’t even an option to renew a token. You basically have to create a new token (and delete the old one) every time.

I maintain a few packages on GitHub, and my first thought was: “Do I really have to do this every 90 days just to keep publishing working?” That would be a little nightmare.

But after reading the announcement and docs, I found there are two major things you can do to make your life easier.

1) Use the CLI to manage tokens

There’s a CLI for managing tokens, so you can set up a script to rotate them automatically — something like:

npm run renew-token

This way, you don’t have to click around the npm website every time.

2) Use OIDC (Trusted Publishing) from GitHub/GitLab

If your workflow runs on GitHub Actions or GitLab CI/CD, you can use OpenID Connect (OIDC) for an even more secure way to authenticate when your workflow publishes a package.

This is zero maintenance once it’s set up: you don’t store a long-lived token at all. Instead, you link your package to an official repository + workflow file, and npm will accept the publish if it comes from that trusted source.

Now I’m happy again — and my setup is even simpler and more secure than it was before :)

I hope this helped. Have a great day!

Create Modal Dialogs in React 🍭

Andreas Riedmüller — Fri, 16 Jan 2026 14:04:37 +0000

Most apps use modal dialogs (aka modals), and implementing a simple one is not that hard: a div with some content, a bit of CSS for the backdrop and positioning, and voilà, you have a modal. But as your app grows, so do the requirements for your modals. Sooner or later, you may find yourself refactoring and debugging a surprising amount of code that is related to modals. At least that’s what happened to me.

Accessibility, keyboard navigation, focus trapping, modal stacking, you name it.

In this guide, I’ll walk you through a concise yet comprehensive modal dialog implementation in React. It’s the result of what I’ve learned about modals in React over the past few years. There are libraries for modals out there, but if you want an implementation you fully own and deeply understand, this guide is for you. We use this architecture in production for the customer dashboard at Userbrain.

I’ve split this article into three parts. First, we’ll build the foundation of the modal framework. Next, we’ll add essential features for usability and accessibility. Finally, we’ll explore more advanced use cases and how to make the most of the system.

What you will learn:

Part I

How to use React Portals to render modals and why.
How to manage multiple modal dialogs that can be open simultaneously.
How to style and control modal stacking visually

Part II

How to trap focus inside a modal.
How to close modals via the Escape key and by clicking outside.
What you need to consider to meet modern accessibility guidelines.
Learn more about the HTML <dialog> element

Part III

Create different kinds of modals
Advanced styling and transitions
How to manage global modals
How to control modals with routes

Let’s start with the end in mind

We’re going to build a React component that can render a modal anywhere in your app. Its open state will be controlled by the parent component.

<Modal isOpen={isModalOpen}>
  Hello, Modal!
</Modal>

A Modal component can also be rendered inside another Modal, which leads to a hierarchical structure of modals.

<Modal isOpen={isModalOpen}>
  Hello, Modal!
  <Modal isOpen={isNestedModalOpen}>
    This is a nested modal.
  </Modal>
</Modal>

A modal dialog, by definition, blocks interaction with the rest of the application.

Because multiple modals can be open at the same time, we also need to determine which one is currently active.

In the following example, two sibling modals and one nested modal are rendered:

<Modal isOpen={isModalOneOpen}>
  This is Modal One.
</Modal>
<Modal isOpen={isModalTwoOpen}>
  This is Modal Two.
  <Modal isOpen={isConfirmModalOpen}>
    Are your sure you want to close Modal Two?
    <button onClick={handleClickYes}>Yes, close!</button>
    <button onClick={handleClickNevermind}>Nevermind</button>
  </Modal>
</Modal>

Let’s think about this example for a second. If all isOpen props are true, which modal should be active?

For Modal Two and its nested modal, the answer is obvious: the Confirm Modal must be active, not its parent, Modal Two.

But Modal One could also be the active modal in this example.

We could use something like the order of appearance in JSX to determine the active modal, but that’s neither intuitive nor easy to implement in React.

A more intuitive approach, in my opinion, is to treat the most recently opened modal as the active one. This also aligns with how the HTML <dialog> element behaves and is the strategy we use.

Now that you have a general idea of what we are going to implement, let’s start writing some code.

1. The portal

Portals are a feature of React that allows you to render JSX into a specific DOM node that can be located anywhere in your document.

We will use Portals to render all modals into a "modal container" node outside the main app tree. By doing so, we make sure our modals aren’t affected by parent styles and we can more easily use features like inert to disable background interaction for better accessibility.

If you want to follow along, start with a fresh TypeScript React project using npm create vite@latest.

First, create a ref to a DOM node where all modals will be rendered to:

// App.tsx
function App() {
  const refModalContainer = useRef<HTMLDivElement>(null);

  return (
    <>
      {/* … */}
      <div ref={refModalContainer} />
    </>
  );
}

Keep in mind that the location of this node in the DOM influences which CSS rules, variable values, and other DOM-dependent behaviors apply to your modals.

You can also use a ref to any other DOM node, such as document.body. I intentionally use a DOM node inside the JSX tree because it requires a bit of extra work, and I want to demonstrate how to do that.

Every modal needs to know about this DOM node, so let’s create a context that provides this information:

// context.ts
type ModalContextType = {
  refModalContainer: RefObject<HTMLElement | null>
} | null;

export const ModalContext = createContext<ModalContextType>(null);

And a ModalProvider component that is responsible for providing this context:

// ModalProvider.tsx
type ModalProviderProps = {
  children: React.ReactNode;
  refModalContainer: React.RefObject<HTMLDivElement | null>;
};

export function ModalProvider({ children, refModalContainer }: ModalProviderProps) {
  const modalContextValue = {
    refModalContainer,
  };

  return (
    <ModalContext.Provider value={modalContextValue}>
      {children}
    </ModalContext.Provider>
  );
}

To make this context easy to consume, we create a useModalContext hook. It throws an error if used outside of a ModalProvider. This is especially helpful when working with TypeScript, as it guarantees that the context exists when the hook is used.

// useModalContext.ts
export function useModalContext() {
  const modalContext = useContext(ModalContext);

  if (modalContext === null) {
    throw new Error("useModalContext must be used within a ModalProvider.");
  }

  return modalContext;
}

Then wrap the entire app in a ModalProvider:

// App.tsx
  const refModalContainer = useRef<HTMLDivElement>(null);

  return (
    <>
      <ModalProvider refModalContainer={refModalContainer}>
        {/* … */}
      </ModalProvider>
      <div ref={refModalContainer} />
    </>
  );

Next, we create a component named ModalPortal that simply renders its children into the modal container:

// ModalPortal.tsx
export function ModalPortal({
  children,
}: {
  children: React.ReactNode;
}) {
  const { refModalContainer } = useContext(ModalContext);

  if (refModalContainer.current !== null) {
    return createPortal(
      children,
      refModalContainer.current,
    );
  } else {
    return null;
  }
}

You can now try using <ModalPortal>, and its children should be rendered into the modal container.

// App.tsx
<ModalProvider refModalContainer={refModalContainer}>
  <ModalPortal>
    Hello, Modal Portal!
  </ModalPortal>
  /* … */
<ModalProvider />

However, there is a catch: The modal container div is only added to the DOM after React has completed rendering, so refModalContainer.current is null during the first render.

"Hello, Modal Portal!" will be rendered into the modal container as soon as you trigger a second render. If you still have the default Vite code in App(), you can click the "count is …" button to trigger another render.

You would not run into this problem if you used an already existing element, such as document.body.

We will fix this issue by adding a mechanism that automatically re-renders the portal if it was not created:

// ModalPortal.tsx
+  const [, forceUpdate] = useReducer((x) => x + 1, 0);
   /* … */
+  const refIsPortalCreated = useRef(false);
+  useEffect(() => {
+    // This effect will run once for any given ref
+    if (refIsPortalCreated.current === false) {
+      forceUpdate();
+    }
+  }, [refModalContainer]);

  if (refModalContainer.current !== null) {
+    refIsPortalCreated.current = true;
    return createPortal(/* … */);
  } else {
+    refIsPortalCreated.current = false;
    return null;
  }

In the render function, we record whether it was possible to create the portal in refIsPortalCreated. The effect then runs afterward and calls forceUpdate if that was not the case.

A neat trick to create a function that forces a re-render is using useReducer. I found this on Stack Overflow some time ago.

Ok, first challenge completed!

🫀The heart of the system

We have already created a ModalProvider and a context. Now we extend both to provide everything necessary to build the <Modal> component in the next step.

ModalProvider will keep track of all modals and determines the stacking order and which modal is currently active.

To achieve this, we’ll store information about all mounted modals in a tree like structure. The stacking order can then be determined by flattening this tree.

When a modal becomes active, all of its nodes (the modal itself and its descendants) are moved to the end of their respective subtrees, ensuring the active branch is on top of the stack.

The modal on the bottom of the tree, will be on top of the stack.

For example, when modal "A2a" becomes active…

App              Z
├─ A             1
│  ├─ A1         2
│  │  └─ A1a     3
│  ├─ A2         4
│  │  └─ A2a     5 (becomes active)
│  └─ A3         6
│     └─ A3a     7
├─ B             8
│  ├─ B1         9
│  │  └─ B1a     10
│  └─ B2         11
│     └─ B2a     12
├─ C             13
└─ D*            14 (is active)

… the tree is reordered so that the active modal moves to the end of the flattened sequence:

App              Z
├─ B             1
│  ├─ B1         2
│  │  └─ B1a     3
│  └─ B2         4
│     └─ B2a     5
├─ C             6
├─ D             7
└▼ A             8
   ├─ A1         9
   │  └─ A1a     10
   ├─ A3         11
   │  └─ A3a     12
   └▼ A2         13
      └▼ A2a*    14 (is active)

Later, when the active modal is closed, we walk upwards and select the the next open modal in the tree to become the active modal:

App              Z
├─ B             1
│  ├─ B1         2
│  │  └─ B1a     3
│  └─ B2         4
│     └─ B2a     5
├─ C             6
├─ D             7
└─ A             8
   ├─ A1         9
   │  └─ A1a     10
   ├─ A3         11
   │  └─ A3a     12
   └─ A2*        13 (is active)
      └─ A2a     14 (was closed)

This example may be more complex than typical app modals, but it illustrates how we manage focus, and stacking order for hierarchical modals.

One thing to keep in mind when looking at this tree is that it shows all mounted <Modal> components and the <Modal> component will only render its content when open. This means that <Modal> will not have children when not open.

The modal tree

Calling it a tree is probably not the right term, because it does not have a root. It’s an array of modal nodes, each of which can have descendants. If I’m not mistaken, this is actually called a forest.

For each modal we will store two pieces of information:

A unique id
If the modal is open

And to manage this tree, we will need utility functions to:

Add a node
Remove a node
Update a node
Get a flat list of all nodes

When updating a node, we check whether it changed to open, and if so, we move the node and its ancestors to the end.

We start by creating a new file, modalTree.ts, where we define the data structure and implement the utility functions to work with the tree—uh, forest.

Damn it, I’ll just call it a tree.

// modalTree.ts
export type ModalTreeData = {
  id: string;
  isOpen: boolean;
};

export type ModalTreeNode = {
  data: ModalTreeData;
  children: ModalTreeNode[];
};

/**
 * Inserts a new modal or updates an existing modal in the forest.
 * If parentId is null, adds/updates the modal as a root node.
 * If parentId is provided, adds/updates the modal as a child of the parent.
 * Also moves the node (and ancestors) to the end if it changes to open state
 * Returns a new forest with the changes applied (immutable).
 */
export function upsertModalNode(
  modalNodes: ModalTreeNode[],
  modalData: ModalTreeData,
  parentId: string | null,
): ModalTreeNode[] {/* … */}

/**
 * Removes a modal from the forest by its ID.
 * If the modal has children, they are also removed (cascading delete).
 * Returns a new forest with the modal removed (immutable).
 */
export function removeModalNode(
  modalNodes: ModalTreeNode[],
  modalId: string,
): ModalTreeNode[] {/* … */}

/**
 * Flattens the forest into a single array of ModalTreeData in depth-first order.
 * For iterating over all modals and determining stack order.
 */
export function flattenModalNodes(
  modalNodes: ModalTreeNode[],
): ModalTreeData[] {/* … */}

Manipulating trees is not part of this article, so I’ll spare you the details of the utility functions here. I’ve moved them to a gist where you can copy the code if needed: modalTree.ts

Inside ModalProvider, we keep a reference to an array of ModalTreeNode objects (the modal tree). Based on this tree, we determine both the id of the active modal and the stacking order, store them in state as activeModalId and modalOrder, and expose them through the context.

// ModalProvider.tsx
export function ModalProvider(/* … */) {
+  const modalsRef = useRef<ModalTreeNode[]>([]);
+  const [activeModalId, setActiveModalId] = useState<string | null>(null);
+  const [modalOrder, setModalOrder] = useState<string[]>([]);

To keep the tree up to date, Modal components notify ModalProvider when they mount, unmount, or when their isOpen state changes. This is done by calling two functions: registerOrUpdateModal or unregisterModal, both of which are provided through the context.

Every time the modal tree is updated, we need to re-evaluate activeModalId and modalOrder. To do this, we create a helper function, update, which derives activeModalId and modalOrder from the current modal tree:

// ModalProvider.tsx
const update = useCallback(() => {
  const flatForest = flattenModalNodes(modalsRef.current);

  const openModals = flatForest.filter((m) => m.isOpen).map((m) => m.id);
  setActiveModalId(openModals[openModals.length - 1] ?? null);

  const newOrder = flatForest.map((m) => m.id);
  setModalOrder((prevOrder) => {
    if (
      prevOrder.length === newOrder.length &&
      prevOrder.every((id, index) => id === newOrder[index])
    ) {
      // only update order if it has changed
      return prevOrder;
    }
    return newOrder;
  });
}, []);

Now we can implement registerOrUpdateModal and unregisterModal. By calling update() in both, we ensure that activeModalId and modalOrder stay in sync with the internal modal tree:

// ModalProvider.tsx
const registerOrUpdateModal = useCallback(
  (modal: ModalInfo) => {
    modalsRef.current = upsertModalNode(
      modalsRef.current,
      { id: modal.id, isOpen: modal.isOpen },
      modal.parentId,
    );
    update();
  },
  [update],
);

const unregisterModal = useCallback(
  (modalId: string) => {
    modalsRef.current = removeModalNode(modalsRef.current, modalId);
    update();
  },
  [update],
);

Using useCallback for these functions is essential because we need stable references in order to use them safely in our Modal component.

Finally, we add activeModalId, modalOrder, registerOrUpdateModal, and unregisterModal to ModalContextType and and provide the relevant data via ModalProvider.

// context.ts
export type ModalInfo = {
  id: string;
  parentId: string | null;
  isOpen: boolean;
};

type ModalContextType = {
  activeModalId: string | null;
  modalOrder: string[];
  refModalContainer: RefObject<HTMLElement | null>;
  registerOrUpdateModal: (modal: ModalInfo) => void;
  unregisterModal: (id: string) => void;
} | null;

// ModalProvider.tsx
const modalContextValue = {
+  activeModalId,
+  modalOrder,
  refModalContainer,
+  registerOrUpdateModal,
+  unregisterModal,
};

The modal component

Now we can build the actual Modal component!

Modal will have three props isOpen, onCloseRequest, and children.

isOpen controls whether the modal is considered open.

onCloseRequest(reason: string) is a function that can be called from anywhere withing the modal to signal that it should be closed.
The component controlling isOpen decides how to handle this request, typically by setting isOpen to false. The reason parameter is useful for distinguishing between different close triggers and selectively ignoring them. For example, if we later add support for closing the modal when clicking outside, the reason could be "click-outside", allowing a specific modal instance to ignore that event and prevent accidental closure.

children represents the modal’s content and is only rendered when the modal is open.

For the Modal component, we once again extend ModalContext to provide modal-specific values that are useful deeper in the tree:

isOpen and onCloseRequest
isActive, which is true when the current modal is the active one.
level, which is initialized to 0 and incremented by 1 if a <Modal> is nested inside another <Modal>. For example, a level of 3 means the current modal has three ancestor modals.
The unique modal ID (modalId), generated using React’s useId().

// context.ts
type ModalContextType = {
  activeModalId: string | null;
  modalOrder: string[];
  refModalContainer: RefObject<HTMLElement | null>;
  registerOrUpdateModal: (modal: ModalInfo) => void;
  unregisterModal: (id: string) => void;
+  isOpen: boolean | null;
+  onCloseRequest: ((reason: string) => void) | null;
+  isActive: boolean | null;
+  level: number | null;
+  modalId: string | null;
} | null;

In ModalProvider, we set these fields to null initially:

// ModalProvider.tsx
const modalContextValue = {
  activeModalId,
  modalOrder,
  refModalContainer,
  registerOrUpdateModal,
  unregisterModal,
+  // Modal-specific fields are initialized to null
+  isOpen: null,
+  onCloseRequest: null,
+  isActive: null,
+  level: null,
+  modalId: null,
};

Next, we create a hook that abstracts all the logic related to registering, unregistering, and updating modal-specific values in the context. The hook returns the updated context value, which we then pass to a provider in Modal for consumers deeper in the tree.

// useModal.ts
export type UseModalArgs = {
  isOpen: boolean;
  onCloseRequest: (reason: string) => void;
};

export function useModal({ isOpen, onCloseRequest }: UseModalArgs) {
  const modalContext = useModalContext();

  const modalId = useId();
  const isActive = modalContext.activeModalId === modalId;

  const level = modalContext.level === null ? 0 : modalContext.level + 1;

  const {
    registerOrUpdateModal,
    unregisterModal,
    modalId: parentModalId,
  } = modalContext;

  // useLayoutEffect is used here to block the browser from
  // repainting the screen before the modal is registered
  useLayoutEffect(() => {
    registerOrUpdateModal({
      id: modalId,
      parentId: parentModalId,
      isOpen,
    });
  }, [registerOrUpdateModal, modalId, parentModalId, isOpen]);

  useLayoutEffect(() => {
    return () => {
      unregisterModal(modalId);
    };
  }, [unregisterModal, modalId]);

  const contextValue = {
    ...modalContext,
    isOpen,
    isActive,
    level,
    modalId,
    onCloseRequest,
  };

  return {
    contextValue,
  };
}

Finally, in the Modal component, we use ModalPortal to render the actual HTML into the modal container. The modals children are rendered only when the modal is open. For testing and demonstration purposes, we also add a simple "Close" button to close the modal.

Note how modalOrder is used to set a CSS custom property for the z-index. While this has no effect yet, we will use it in the CSS to ensure that the visual stacking of modals stays in sync with the defined modal order. This is necessary because the rendered HTML inside the modal container does not reflect the modal order we defined.

// Modal/index.tsx
import styles from "./styles.module.css";

type ModalProps = {
  isOpen: boolean;
  onCloseRequest: (reason: string) => void;
  children: React.ReactNode;
};

export function Modal({ isOpen, onCloseRequest, children }: ModalProps) {
  const { contextValue } = useModal({ isOpen, onCloseRequest });

  const { modalId, modalOrder } = contextValue;

  return (
    <ModalContext.Provider value={contextValue}>
      <ModalPortal>
        <div
          id={modalId}
          style={
            {
              "--modal-z-index": modalOrder.indexOf(modalId) + 1,
            } as React.CSSProperties
          }
        >
          {isOpen && (
            <div className={styles.modalWrapper}>
              <div className={styles.modalWindow}>
                {children}
                <div>
                  <button onClick={() => onCloseRequest?.("close-button")}>
                    Close
                  </button>
                </div>
              </div>
            </div>
          )}
        </div>
      </ModalPortal>
    </ModalContext.Provider>
  );
}

Styling the modal

Last but not least, we add some CSS to style the Modal.

As mentioned earlier, we use --modal-z-index to control the z-index of our modals. Before doing so, we need to ensure that the modals live in their own stacking context.

To achieve this, we assign an explicit z-index value to the modal container. Using a value of 0 creates a new stacking context while preserving the normal document order.

// App.tsx
-      <div ref={refModalContainer} />
+      <div ref={refModalContainer} style={{ zIndex: 0, position: "relative" }} />

Because the modal container appears after the rest of the app in the DOM, a z-index of 0 still places the modals above everything else—unless another element explicitly sets a higher z-index (i.e., greater than 0). In that case, that element would appear above the modals. For this reason, it's generally a good idea to also wrap the rest of the app in its own stacking context.

All that's left now is to set z-index for .modalWrapper:

.modalWrapper {
  position: fixed;
  z-index: var(--modal-z-index);
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
  overflow: auto;
  display: flex;
  align-items: flex-start;
  background-color: rgba(0, 0, 0, 0.32);
  padding: 0.5rem;
}

The .modalWrapper element acts as the backdrop. It uses position: fixed and spans the entire viewport. We enable scrolling with overflow: auto; in case the modal window exceeds the available space. Using display: flex allows us to easily position the modal window within.

The styles of the .modalWindow are mostly a matter of taste; this is what I came up with for a simple modal window:

.modalWindow {
  position: relative;
  box-sizing: border-box;
  margin: 3rem auto 0;
  padding: 1rem;
  max-width: 100%;
  border-radius: 1rem;
  background: white;
  box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);
}

Alright, that's it for the first part. Now let's test the modal system.

Using the Modal component

First you can remove the ModalPortal from App()–if you haven't already–and add a state variable to control the new Modal component:

function App() {
/* … */
+  const [isModalOpen, setIsModalOpen] = useState(false);
/* … */
      <ModalProvider refModalContainer={refModalContainer}>
        {/* … */}
-        <ModalPortal /* … */ />
+        <button onClick={() => setIsModalOpen(true)}>Open Modal</button>
+        <Modal
+          isOpen={isModalOpen}
+          onCloseRequest={() => setIsModalOpen(false)}
+        >
+          Hello, Modal!
+        </Modal>
      </ModalProvider>
      <div ref={refModalContainer} />
/* … */

After clicking on "Open Modal" this is what you should see:

We now have a working basic modal dialog, nice! 🥳

Now let’s try a more advanced experiment to test nested modals. We’ll create a component that serves as the modal's content and includes another modal that can be opened. We then use this component recursively as the modal content. This should allow us to open an infinite chain of nested modals. If that works, we know nested modals are functioning correctly. 🙂

function ModalContent() {
  const [isNestedModalOpen, setIsNestedModalOpen] = useState(false);
  const { level } = useModalContext();

  return (
    <div>
      <p>Modal level: {level}.</p>
      <button onClick={() => setIsNestedModalOpen(true)}>
        Open a nested modal
      </button>
      <Modal
        isOpen={isNestedModalOpen}
        onCloseRequest={() => setIsNestedModalOpen(false)}
      >
        <ModalContent />
      </Modal>
    </div>
  );
}

Inside ModalContent, we can consume level from ModalContext and display it in the modal so we can see which level we’re currently on.

Now, use ModalContent instead of "Hello, Modal!":

      <Modal isOpen={isModalOpen} onCloseRequest={() => setIsModalOpen(false)}>
-        Hello, Modal!
+        <ModalContent />
      </Modal>

Yay, this works.

Next up, we’ll dig into some important aspects to improve the usability and accessibility of the modals:

How to trap focus inside a modal
How to close modals via the Escape key and by clicking outside
What to consider to meet modern accessibility guidelines

Thanks for reading!

I hope you had fun and gained some useful insights from this part of the guide on building modal dialogs in React.

If you did not follow along or something wasn't that clear, you can find the full source code with working examples on my GitHub Profile.

https://github.com/receter/react-modal-dialog/tree/part1
(Branch: part1)

I'm all ears for any thoughts you'd like to share.

Why would a real pirate `npm run` when they can `npm rum` instead? 🏴‍☠️🥃

Andreas Riedmüller — Mon, 12 Jan 2026 10:43:30 +0000

Finding good things isn’t easy.

Andreas Riedmüller — Thu, 04 Sep 2025 11:56:23 +0000

The stuff that’s easy to find is usually monetized. And if it’s monetized, chances are it was made with money in mind. The truly good things hide behind the noise—the loud, obvious, and easy-to-digest.

You have to dig. You have to put in effort to discover good software, music, art, literature, and more. There is quality in the mainstream—because there has to be. But often, even greater quality lives in the niches, where it’s free. Free from the pressure to monetize. Free from the need to meet expectations. Free from compromise.

Of course, there’s also plenty of trash. But if you keep searching, if you keep digging, your taste sharpens, and with it, your world expands.

Just typing “Techno” into Spotify and expecting to find greatness is naïve. The treasures lie deeper.

Instead, try exploring the subgenres of techno. Ask, for example, Perplexity: “Which SoundCloud accounts have good DJ sets for this subgenre?” Suddenly your path becomes less predictable. You might stumble across a DJ with only 500 followers who happens to have uploaded an 800-play mix—his personal collection of strange and wonderful techno.

The same is true for software, programming libraries, tutorials, live advice, and so on.

Always remember: don’t get too comfortable. Stay a little awkward, and keep doing things in your own unique way.

AI chats aren’t replacing thinking—they’re forcing it. Since I started using them, I capture and structure my problems more often. And wild thing: That alone is sometimes more valuable as the answer I get.

Andreas Riedmüller — Thu, 28 Aug 2025 08:51:22 +0000

Default Component Styles

Andreas Riedmüller — Mon, 25 Aug 2025 14:31:51 +0000

I remember years ago when I first used React Select, I wished it came with fewer assumptions. Instead of simply adding what I needed, I had to start by undoing what was already there.

But on the flip side, having no styles at all isn’t much better. Totally unstyled components can take some time to get right, sometimes that is even more work than undoing some styles.

So there’s this tension: you want to ship a sensible baseline of styles, but avoid going too far into the details.

Modern component libraries often ship with both pre‑styled components and unstyled (headless) variants.

Tailwind Labs for example offers Headless UI—unstyled, accessible components for React and Vue—and Catalyst, a React UI kit built with Tailwind (and using Headless UI) that provides opinionated, production‑ready building blocks.

MUI introduced the unstyled component library Base UI fairly recently in its history.

And Adobe maintains React Aria—unstyled components and hooks focused on behavior, accessibility, and internationalization—alongside React Spectrum, the fully styled React implementation of Adobe’s Spectrum design system.

With System42, I want to take a similar approach: a single package, sys42/ui, that provides both components with thoughtful, themeable defaults and, at the same time, hooks and clear guidance so you can easily create app‑local variants with full control over styles and markup.

For every component, there are two hooks you can use to build your own component on top of the existing one: one named after the component (for example, useButton), which includes styling and styling‑related props; and another prefixed with Base (for example, useBaseButton), which is free of styling opinions.

Use the first when you just want to alter the rendering logic—for example, to create a button component that renders an a instead of a button:

import { createComponent } from "../helpers";

import { ButtonProps, useButton } from "./useButton";

export const ButtonA = createComponent<ButtonProps, "a">("a", (hookOptions) => {
  const { elementProps, elementRef } = useButton(hookOptions);
  return <a {...elementProps} ref={elementRef} />;
});

When using the base hook, you can pass a middleware‑like function as the second argument to apply style‑related props to the rendered element. Here’s an example of a Button with custom styles using CSS Modules:

import { BaseButtonProps, createComponent, useBaseButton } from "@sys42/ui";
import { cn } from "@sys42/utils";

import styles from "./styles.module.css";

export const Button = createComponent<BaseButtonProps, "button">(
  "button",
  (hookOptions) => {
    const { elementProps, elementRef } = useBaseButton(hookOptions, (draft) => {
      draft.elementProps.className = cn(
        draft.elementProps.className,
        styles.button,
      );
    });
    return <button {...elementProps} ref={elementRef} />;
  },
);

One drawback of this approach: if you name your local components identically to the library’s (for example, a local Button), you must ensure your imports reference the local Button rather than the library’s default Button export.

One solution is to create a local alias that points to a file where you export your local components; most editors will prefer that path for auto‑imports.

Additionally, you could use an ESLint rule that warns when a library component is used while a local version exists.

I hope you found reading this interesting. If you have any thoughts or ideas on this topic, let me know!

System42: My Journey Building a New Design System

Andreas Riedmüller — Wed, 20 Aug 2025 06:51:25 +0000

Now, as summer comes to an end, I’m eager to continue working on System42. I’ve been working on this project for some time, with the goal of creating a design system that is well-documented, easy to use, and straightforward to extend — a set of rules and tools that help bring ideas to life quickly.

While it remains experimental, it already feels much closer to what I originally envisioned than any of my earlier attempts.

Two years ago, I wrote an article on how to create a React component library using Vite’s library mode. It was actually a byproduct of my search for a simple—but not overly opinionated—setup for shipping a component library. I guess it must have hit a nerve, since it received way more attention than any of my other posts. And your comments helped me a lot refining the solution.

Since writing (and getting feedback) has always helped me better understand problems and find good solutions, I’ve decided to start sharing regular updates about my thoughts and progress on System42 here.

So, if you’d like to follow along with the struggles, insights, and lessons learned from someone who tries hard to build a good design system from scratch, stay tuned.

What helps me with end-of-day reporting

Andreas Riedmüller — Tue, 19 Nov 2024 08:47:33 +0000

Ever feel like your day ends and you can’t quite remember what you actually accomplished? Or do you get so absorbed in a task that you forget your original goal?

That used to be me too. Staying focused and keeping track of my progress felt like a constant challenge.

So, I built something to help: a simple web extension to keep me on track.

Here’s how it works:

When I start working, I set my focus by writing down the task I want to accomplish.
If I switch tasks, I log and update my focus.
If I lose track, I glance at my focus to remind myself what’s important.
By the end of the day, I have a log of all my focused tasks and end-of-day reporting gets pretty easy.

If this sounds like something that could help you stay focused and feel more accomplished, check it out:

Google Chrome
https://chromewebstore.google.com/detail/focus-log/pgoamholhbaeiokhfcchhbaicndfpcjn

Firefox
https://addons.mozilla.org/de/firefox/addon/focus-log/

Source (GitHub)
https://github.com/receter/focus-log-extension

I’d love your feedback. How do you currently stay focused and keep track of what you did?

The Non-null Assertion Operator (!) in TypeScript

Andreas Riedmüller — Tue, 24 Sep 2024 07:52:29 +0000

Let’s face it—TypeScript’s type safety is amazing, but there are times when you know more about your code than TypeScript does. One situation that comes up a lot is when TypeScript insists that a value might be null or undefined, even though you're 100% sure it's not. This is where the Non-null Assertion Operator ! comes into play.

Below is a simple code snippet demonstrating when this operator is unnecessary. TypeScript infers that video in the log statement is not null:

if (state.video !== null) {
  console.log(state.video.title); // TypeScript is happy.
}

But if you’re working with more complex conditions, for example updating nested properties in a produce call (for those who love immer!), TypeScript might not infer everything perfectly. It’ll think, “What if video suddenly becomes null?” To solve this, you use a type assertion:

if (state.video !== null) {
  const updatedState = produce(state, (draftState) => {
    draftState.video.title = "Hello Video!"; // TypeScript complains: 'draftState.video' is possibly 'null'.ts(18047)
  });
}

if (state.video !== null) {
  const updatedState = produce(state, (draftState) => {
    draftState.video!.title = "Hello Video!"; // TypeScript is happy again :-)
  });
}

That ! is saying to TypeScript: “I know what I’m doing. Trust me, this value is not null or undefined.” It’s a little trick to bypass TypeScript's complaints when you know it’s safe.

To be clear, I’m not saying you should sprinkle ! everywhere. If you use it carelessly, you might end up with bugs because you bypassed TypeScript’s safety net. But when you know your logic is solid, it’s a great tool to have.

For example, when working with APIs, TypeScript might not always infer the structure exactly as you need, especially with libraries that don’t have the strongest types. Instead of wasting time creating elaborate type guards or refactoring everything, you can assert certain fields as non-null using !.

I use this sparingly, but if the situation requires it, ! saves me time and unnecessary additional checks in the code.

How to Install Prettier in Your Codebase and VSCode

Andreas Riedmüller — Wed, 14 Aug 2024 09:49:33 +0000

Prettier

Prettier is an opinionated code formatter with support for multiple languages.

Since I started using Prettier, I don't want to work code without it anymore. Despite having some concerns in the beginning (the forced line width for example), I fell in love with default settings.

Install and Configure Prettier

Installing Prettier is easy, here are the steps in a nutshell. You can also follow the official installation guide.

First you need to install the exact version of prettier locally. This ensures that everyone will use the exact same version for formating code in the project.

npm install --save-dev --save-exact prettier

Next you need to create the Prettier configuration file .prettierrc and .prettierignore (optional) in the root of your project.

You can run this command to create the default configuration file with an empty object:

node --eval "fs.writeFileSync('.prettierrc','{}\n')"

The .prettierignore file works in the same way as a .gitignore file. In fact, Prettier already follows the rules set out in your .gitignore, so you might not even need one:

📖 By default prettier ignores files in version control systems directories (".git", ".sl", ".svn" and ".hg") and node_modules (unless the --with-node-modules CLI option is specified). Prettier will also follow rules specified in the ".gitignore" file if it exists in the same directory from which it is run.

Here is an example .prettierignore to skip all HTML files:

# Ignore all HTML files:
**/*.html

Format all existing code

Before continuing with formating the whole codebase, commit your changes. I also recommend merging all open pull requests, as a lot of files will be affected.

Now run this command in the root folder of your project to format all files:

npx prettier . --write

ℹ️ using npx here ensures that the locally installed version of Prettier is executed. This is important if you also have prettier installed globally.

Now all your project files should be nicely formated. 🧹✨

Install the Prettier VSCode Extension

Next you can setup a Prettier plugin for your IDE. I use Visual Studio Code, but there are also plugins for many other editors.

For VSCode, install this extension: esbenp.prettier-vscode

Having done that you can navigate to the VSCode settings and search for "formatter". Here you could set Default Formatter to esbenp.prettier-vscode.

However, if, like me, you work on many different projects and not all of them have Prettier, you will probably leave it at the default setting (None).

Instead you can set the default formatter in the local VSCode settings file (.vscode/settings.json) of the projects you use prettier.

To be sure any language specific global VSCode settings are overriden by the local config, you might need to specify defaultFormatter for each language individually.

Here is an example .vscode/settings.json for reference:

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[javascriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[css]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[html]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[jsonc]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}

The best simple JavaScript project setup to work efficiently and keep your code base clean

Andreas Riedmüller — Tue, 30 Jul 2024 06:50:33 +0000

To be honest, "The best…" for anything is hard to argue and in most cases not true. Nevertheless, I chose this title because I'm documenting what I currently consider to be "the best" setup for my JavaScript projects.

This is not my first shot, but the result of my experiences over the last few years. I would also like to take this opportunity to thank my colleague Jay Watts for the many suggestions that have led to the current state of this setup.

The setup is quite simple and most of the time default configs are used.

🤓 Whilst there is a link to a GitHub template (React/Typescript) at the end of this article, following the steps below doesn't take long and I think it's worth doing it manually, especially the first time. If you feel like this is already to much effort, you probably don't need any of this and can just scaffold a default Vite project. You can always add these features later if you miss them.

Here is my take on "the best" setup in a few bullet points:

GitHub
Vite
Prettier
Import sorting (eslint plugin)
lint-staged
husky (pre-commit/pre-push hooks)

1. Create a new Vite project

Vite made my life so much easier by providing a simple way to setup a new bundler project with very good default configurations. It is just so powerful that you can easily bootstrap a setup that works out of the box in seconds. For many just creating a new Vite project might be good enough already.

To create a new Vite project all you need to do is run this command and follow the instructions:

npm create vite@latest

? Project name: › my-project
? Select a framework: › React
? Select a variant: › TypeScript

cd my-project

npm i

2. Init Git and create a `.nvmrc`

This are the two things I do every time I setup a new node project.

Early first commit

git init
git add --all
git commit -m "blank vite react/typescript project"

Create a .nvmrc

This file contains the version of node that is recommended for the project. If nvm is installed on your system, you can run nvm use in the project folder and nvm will automatically switch to the specified version.

node --version > .nvmrc
git add .nvmrc
git commit -m "create .nvmrc file"

💡Pro Tip You can set up a script that will automatically call nvm use whenever you enter a directory that contains an .nvmrc

3. Prettier

Since I started using Prettier, there's no going back for me. Every time I save, my code is automatically formatted according to a uniform standard. I decided to just follow their default rules and got used to it quickly. This is a big time saver.

You can read my in depth article on how to install and configure Prettier (including configuring your editor) or follow the official installation guide

Here are the steps in a nutshell:

Install Prettier

npm install --save-dev --save-exact prettier
node --eval "fs.writeFileSync('.prettierrc','{}\n')"

git add --all
git commit -m "install prettier"

Format all files

npx prettier . --write

git add --all
git commit -m "format files with prettier"

4. Import sorting

This is another feature I don't want to miss anymore. Especially when your editor automatically adds imports it is cumbersome to sort them manually.

I have already written a separate article on this topic, which also contains my custom sorting configuration: Automatic import sorting with ESLint.

Here are the basic steps to set up automatic import sorting for your project:

Install ESLint plugin

I currently use ESLint for sorting imports. My plugin of choice is eslint-plugin-simple-import-sort https://github.com/lydell/eslint-plugin-simple-import-sort

npm install --save-dev eslint-plugin-simple-import-sort

git add --all
git commit -m "install eslint-plugin-simple-import-sort"

Configuration

Enable the plugin and rule in your eslint config:

// .eslintrc.cjs
--  plugins: ["react-refresh"],
++  plugins: ["react-refresh", "eslint-plugin-simple-import-sort"],

// .eslintrc.cjs
  rules: {
++    "simple-import-sort/imports": ["error"],

If you have set up the plugin in this way, you will receive ESLint errors if the imports are not sorted according to the rules. You can now run fix for all files to automatically fix these issues and sort your imports.

npx eslint --fix .

I highly recommended you setup your editor to "fix" automatically every time you save a file. You can find detailed instructions to set this up for VSCode in my automatic import sorting article.

git add --all
git commit -m "configure eslint-plugin-simple-import-sort"

5. CSS property sorting

I've never been a fan of sorting CSS properties alphabetically. Why should text-related styles, for example, be scattered? At the same time I do like sorting and have had my own (admittedly inconsistent) way of organizing properties.

Recently I stumbled upon prettier-plugin-css-order which uses concentric-css (per default) to sort CSS properties. I just started using this, and I do have a very good feeling about it.

There is also the option to sort alphabetically (🙂‍↔️) and SMACSS (another opinionated sorting approach).

This is what concentric-css does:

Order properties applying outside the box model, moving inward to intrinsic changes.

Positioning
Visibility
Box model
Dimensions
Text

Install prettier plugin

npm install --save-dev prettier-plugin-css-order

The docs suggest to also explicitly install postcss but I think this can/should be skipped because Vite does this already.

Configuration

.prettierrc
{
  "plugins": ["prettier-plugin-css-order"],
  "cssDeclarationSorterKeepOverrides": false
}

The config cssDeclarationSorterKeepOverrides is true per default, but it is recommended to turn this off if you can.

Read more about what this does here: https://github.com/Siilwyn/css-declaration-sorter#keepoverrides

6. Pre-Commit and Pre-Push hooks

With Husky you can run checks on the code you are about to commit/push. I use this to enforce the formatting rules for all commits and check for Typescript issues before pushing. The fact that this rules trigger from time to time is a good indicator that they are indeed very helpful for me :-)

And lint-staged is yet another tool that can run linters on staged files only.

As per Prettier docs you can run this command to automatically setup lint-staged and husky with a pre-commit hook. It will also add the necessary configuration to your package.json

npx mrm@2 lint-staged

Instead of the generated configuration I use this setup which does not allow you to commit anything with ESLint warnings and formats all files with prettier:

// package.json
…
  "lint-staged": {
    "*.{js?(x),ts?(x)}": [
      "eslint --max-warnings 0",
      "prettier --write --ignore-unknown"
    ],
    "!*.{js?(x),ts?(x)}": "prettier --write --ignore-unknown"
  }
…

git add --all
git commit -m "install/configure husky and lint-staged"

7. TypeScript checks with pre-push hook

Because for Typescript the context of "only staged files" is not enough, you need to run tsc on the whole project instead of using lint-staged. As this takes a little longer, I do not want to run this for every commit but only before pushing code.

Add a pre-push file in the .husky directory:

mkdir -p .husky && touch .husky/pre-push

Copy this script to the created file:

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

printf "\n[PRE-PUSH HOOK] Running tsc checks. This might take a few moments.\n\n"

npx tsc --noEmit

git add --all
git commit -m "add pre-push TypeScript check"

8. Claude Code

Update 16.02.2026: Recently I work a lot with Claude Code and there are two things I have added to my template recently:

Updated .gitingnore to ignore local config files

# Claude
.claude/*.local.*

Added a hook that automatically formats and autofixes (for example for import sorting) all code in src

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier ./src --write && npx eslint --fix 'src/**/*.{js,jsx,ts,tsx}'"
          }
        ]
      }
    ]
  }
}

Done!

That's it, you can now start doing changes and enjoy your setup. Have fun!

And please let me know if this article has helped you. I am always happy to receive feedback and hear about your experiences.

GitHub Template Repository: https://github.com/receter/my-vite-react-template

Avoiding CSS order of appearance problems with CSS Modules

Andreas Riedmüller — Wed, 17 Apr 2024 11:42:17 +0000

When I started web development, I wrote pure CSS, then I moved on to BEM (Block, Element, Modifier) methodology and LESS/SASS, and eventually adopted PostCSS and CSS Modules when I started using modern JavaScript frameworks and bundlers.

For me, CSS Modules primarily solved the inconvenience of managing unwieldy long class names to avoid global namespace pollution and accidental style overrides. And despite all the new CSS libraries popping up lately, I still love the simplicity of using CSS modules.

In this article I want to shed light on one challenge I've encountered when using CSS Modules:

Position and order of appearance

In CSS (Cascading Style Sheets) the order in which rules appear affects the final styling of elements. Later-defined CSS rules have higher precedence and can override earlier ones. This is one of four stages in the cascade algorithm, the others are specificity, origin, and importance.

Sometimes, the order of CSS rules can create confusing scenarios. Imagine you have a div and apply multiple classes that set color like this:

<div class="red blue">Hello World</div>

What color will "Hello World" have? To be able to answer this question with certainty, you need to know the order in which the classes are defined.

In this case, the obvious solution is to use only one class:

<div class="red">Hello World</div>

However, the reality looks more like this:

<button class="my-fancy-button blue">Send Hello</button>

.my-fancy-button is a class that defines the appearance of a fancy button, and .blue is a utility class to set the color blue in this context. For this to work, you will have to to make sure that .blue is defined later.

Bundlers

This next example illustrates an order of appearance problem you may encounter when using CSS Modules in any bundler setup.

Let's say, you create a React component and style it using a custom class. In addition the component is designed to accept a className prop that can be used to pass an additional class from outside.

import { button } from "styles.module.css";

function Button(props) {
  return (
    <button className={concatClassNames(button, props.className)}>
      {props.label}
    </button>
  );
}

Subsequently, you use this component, utilizing a helper class to override specific styles.

import { Button } from "components/Button";
import { blue } from "../../helpers.module.css";

function BlueButton() {
  return (
    <div>
      <Button className={blue} label="Click Me" />
    </div>
  );
}

This will work like expected because bundlers typically sequence generated/imported CSS based on the first occurrence. You can think about it like a global style sheet; whenever CSS is imported, it's appended to a list of style rules.

blue is imported after Button, so it is added later and overwrites the color defined by the local class button imported inside Button

The import order is crucial here; if you would import blue before Button, the utility class wouldn't be able to override the color anymore:

// If the utility class is imported earlier, it doesn't 
// have the ability to override styles from Button.
import { blue } from "../../helpers.module.css";
import { Button } from "components/Button";

Ok, so we just need to make sure to always import such utility classes last, right?

In general this is true, but it might be more difficult than you expect, hang on.

The hidden first occurrence

Let’s assume you import BlueButton and also the same helper class blue in another file:

import { BlueButton } from "components/BlueButton";
import { MyHeading } from "components/MyHeading";
…
// The utility class is imported last (in this file)
import { blue } from "../../helpers.module.css";

function MyCoolInterface(props) {
  return (
    <div>
      <MyHeading className={blue}>
        Click the blue button:
      </MyHeading>
      <BlueButton />
      …
    </div>
  );
}

Despite blue being imported last in this file, it's first occurrence is inside BlueButton. This means that the class blue will be added ahead of any CSS imported after BlueButton. In this example the class blue won't have precedence to override styles defined in MyHeading.

While in this particular case you could theoretically move the MyHeading import to the top, there are situations where reordering imports merely transfers the problem to another location.

Avoiding hidden first occurrences

An effective solution to avoid this problem would be a steadfast rule: always import CSS in an application only once, and never in multiple locations.

By following this rule, you ensure that each import is the first occurrence, and you can stay confident about the sequence. For each file where this rule is not followed, expect that the rules might spontaneously receive lower precedence than they currently have in your context.

To use classes in multiple locations you can still import the styles once at a higher level, such as your main file or an App component. Then share the classes by passing them down to children.

In React, you could do this via the Context API:

import App from "./App"
import * as helperStyles from "helpers.module.css"

<MyContext.Provider value={{ helperStyles }}>
  <App />
</MyContext.Provider>

But you could still run into order of appearance issues.

Imagine you create a component MyHeading that uses a class provided by MyContext and in addition accepts a className from outside:

function MyHeading({children, className}) {
  const { helperStyles } = useContext(MyContext);
  return (
    <h1
      // This can get you into trouble
      className={concatClassNames(helperStyles.green, className)}
    >{props.children}</h1>
  )
}

The file helpers.module.css defines the two utility classes blue and green:

.blue {
  color: blue;
}

.green {
  color: green;
}

When you subsequently use MyHeading and pass it the blue class obtained from MyContext like <MyHeading className={blue} />, the blue class and the red class would both be applied. And blue won't have sufficient precedence to override the color because it is defined first in helpers.module.css.

I do like the pattern of concatenating class names across multiple levels in the component tree. But to keep this pattern intuitive you need to make sure that the precedence of rules resembles the hierarchy in your components.

You can accomplish this by adhering to the aforementioned rule and avoiding the combination of shared class names at multiple levels.

Conclusion

While CSS Modules and similar tools offer elegant solutions to avoid namespace conflicts, managing the precedence of style rules is still relevant.

Thank you for reading! Let me know if you found it worthwhile reading and I hope this article has piqued your curiosity. Feel free to share your thoughts and experiences on this topic in the comments below.