DEV Community: Martin

Finding all via vscode fulltextsearch

Martin — Mon, 16 Jun 2025 14:00:13 +0000

When I need to find all occurrences in my codebase where a certain component is used and a certain property is provided usually my first attempt does find nothing. Because this is where we need multiline matching; and I can't memorize how it's done. Have to look it up every single time (Stackoverflow).

So I'll now write it down here; for the next time I will need it.

Dear future me,

so we're looking for <MyComponent> and need to find any place that sets the property foobar, is that right?
Use the following pattern via the vscode fulltextsearch box with RegEx enabled:

<MyComponent(.|\n)+?foobar=

What's wrong with useId()? (React and Preact)

Martin — Sun, 08 Jun 2025 16:21:55 +0000

TLDR: useId will produce duplicated IDs when you have more than one app root. Read on and find out what can be done about it.

Introduction

Let's start at the beginning: why do we even have a useId hook? You can skip the introduction if you are familiar with the hook itself and the reason for its existence.

DOM IDs in Components

When we need to associate a DOM element with another one, like in the following snippet the <label> and the <input>, we usually need to set an HTML id attribute.

<span>Do you want to receive exciting news about all our products?</span>
<input type="checkbox" id="spam-galore" />
<label htmlFor="spam-galore">Yes, please send more spam my way</label>

Nesting the <input> inside the <label> is an alternative way to associate the two elements without using an ID, but this is not always feasible; and there are other element types where nesting is not possible, which is the case in the following snippet with <input> and associated <datalist>.

<input list="preferred-conference-swag" />
<datalist id="preferred-conference-swag">
  <option value="Hoodie"></option>
  <option value="Ballpoint Pen"></option>
  <option value="Fidget Toy"></option>
  <option value="Stickers"></option>
</datalist>

A hard-coded ID only works correctly if there is never more than one instance of the component in the DOM.
So for all other cases we need to solve this by generating a dynamic ID; ideally one that stays the same as long as the component instance exists (i.e. as long as it is mounted).
This can be done a hundred different ways and isn't exactly rocket science (see section Roll your own for inspiration).
So every project sooner or later had its own custom hook implementation to provide dynamic and lifetime-stable IDs.

With release 18.0.0 (March 29, 2022) React introduced the useId hook.

useId is a new hook for generating unique IDs on both the client and server, while avoiding hydration mismatches.
(from the release notes)

While implementing our own random-ID-generating hook isn't much of a challenge, we would run into problems when our app were to use server-side rendered (SSR) parts and the IDs generated on the server would not match the IDs generated on the client.
The useId hook generates a deterministic ID that would be the same client-side and server-side.

This would make all those custom hooks obsolete and a thing of the past. Or so I thought.

A Discovery of Trouble

I was using the new hook from time to time without noticing any issues for a while. But a few days ago I ran into a strange bug: a label associated with a checkbox would not correctly toggle the checkbox when clicked. Following a suspicion I quickly verified that the association was working fine on the very first input-and-label pair in my DOM, and discovered that all later pairs used the very same ID; so all the other labels were all associated with the very first checkbox.

My application is not the classical SPA; it's a collection of smart components that can be placed in a regular HTML web page; and each placed component constitutes its own app root. (Aside: A while ago I read somewhere that this is nowadays called islands.)
And the same component might be placed multiple times into the same page.

As it turns out, the useId hook will produce duplicated IDs when used in a multi root scenario.
And this is an issue for both implementations: React and Preact.
If you are interested to see the bug demonstrated: I created a small reproduction scenario.

An Attempt at an Explanation

As far as I understand, the requirement to produce the same ID for any given component instance in the virtual DOM when rendered client-side or when rendered server-side bars the useId implementation from using any randomness; only the component position in the virtual DOM and/or the calling order (so anything that is stable w.r.t. client-side vs server-side rendering) can be used to generate an ID that is stable but also unique within the same app.

An Attempt at a Solution

Both the React team and the Preact team are aware of the issue.

React

React provides a way to resolve the problem manually by specifying a shared prefix for all generated IDs.

If you render multiple independent React applications on a single page, pass identifierPrefix as an option to your createRoot or hydrateRoot calls. This ensures that the IDs generated by the two different apps never clash because every identifier generated with useId will start with the distinct prefix you’ve specified.

const root1 = createRoot(document.getElementById("root1"), {
  identifierPrefix: "my-first-app-",
});
root1.render(<App />);

const root2 = createRoot(document.getElementById("root2"), {
  identifierPrefix: "my-second-app-",
});
root2.render(<App />);

It is certainly not ideal that the issue has to be resolved manually, but I'm sure given the requirement mentioned earlier that there really isn't any other way without ditching stable between client-rendered and server-rendered.

Preact

The Preact team is aware of the issue, but has not yet mirrored the identifierPrefix feature.

Luckily for me the server-side rendering aspect is irrelevant as my components are only ever rendered client-side.
So my solution to the problem currently is to just use a custom hook instead of useId, to generate dynamic and lifetime-stable IDs and using randomness to my heart's content; see section Custom Hook with Randomness for implementation details.

But what if you are not so lucky? When your setup uses Preact with client-side and server-sider rendering?
In this case I would recommend to emulate the identifierPrefix feature until it is provided by Preact out of the box; see section identifierPrefix in Preact for implementation details.

Roll your own

This section provides code examples for both approaches:

a custom hook with randomness (client-side-only approach)
identifierPrefix in Preact (client-side and server-side)

Custom Hook with Randomness

One implementation of my homebrewn useStableID could look like this:

import { getRandomID } from "any-random-ID-thing-would-work-here";

const ids = new Map();
export const useStableID = () => {
  const ref = useRef({});
  if (!ids.has(ref.current)) {
    const existingIDs = [...ids.values()];
    let newID;
    do {
      newID = getRandomID();
    } while (existingIDs.includes(newID));
    ids.set(ref.current, newID);
  }
  return ids.get(ref.current);
};

You could even use Math.random() here because every new ID is checked against the existing IDs to prevent clashes.

export const getRandomID = () => `id-${Math.random()}`;

Another, shorter implementation using GUIDs could look like this:

import { v4 as uuidv4 } from "uuid";

export const useStableID = () => {
  const [id] = useState(() => uuidv4());
  return id;
};

Here checking each newly generated ID against the existing IDs can be omitted because GUIDs / UUIDs are unique with sufficient probability (that's really the whole point of them).

identifierPrefix in Preact

Disclaimer: I haven't tried this out yet; but to the best of my knowledge this should work just as expected.

You can emulate the identifierPrefix feature by wrapping your root in a context provider, passing down a prefix to your patched useId hook.

The context:

import { createContext } from "preact";

export const IdentifierPrefix = createContext(null);

Providing a prefix:

import { IdentifierPrefix } from "./identifierPrefixContext";

const root1 = document.getElementById("root1");
render(
  <IdentifierPrefix.Provider value="my-first-app-">
    <App />
  </IdentifierPrefix.Provider>,
  root1
);

const root2 = document.getElementById("root2");
render(
  <IdentifierPrefix.Provider value="my-second-app-">
    <App />
  </IdentifierPrefix.Provider>,
  root2
);

The patched useId hook:

import { useContext } from "preact/hooks";
import { IdentifierPrefix } from "./identifierPrefixContext";

export const usePatchedUseId = () => {
  const identifierPrefix = useContext(IdentifierPrefix);
  const id = useId();
  return `${identifierPrefix}${id}`;
};

Using usePatchedUseId everywhere instead of useId should now solve your problem.
You'll need to provide the same prefix values on the client and on the server.

Future Updates and Further Reading

I will try to keep this article updated when further information comes to my notice or when there is some progress on the Preact issue.

My initial research also turned up the following links:

mirroring react's useId hook in preact was discussed here
the initial preact implementation of the useId hook had some issues, which were reported here

Beware: Invalid Selectors with SCSS

Martin — Wed, 01 May 2024 13:18:28 +0000

It is very easy to inadvertently create invalid selector lists when using SCSS; causing the whole rule block to be ignored during runtime.
I found this out the hard way yesterday.
Let's have a look at what I did and what I learned from it.

Act I - Causing the Problem

I set out to improve our project's CSS reset rules and noticed that after the change some styles did not get applied anymore.
What had happened?
Our existing CSS reset rules are scoped to be only applied to the part of the DOM our app is responsible for, the app root is classed with .scoped-reset (hashed during build) so the reset affects only this very element and everything beneath it.
In order to not need to duplicate the reset value assignments they are placed in a mixin (I'm aware that this could be rewritten to remove the need for a mixin, but the code is as it is at the moment).
And some time ago someone added lines to visually hide scrollbars if not explicitly opted-in via special data attribute.
This all worked and was probably not touched for a year or even longer.
So before my change it looked like this:

@mixin reset() {
  box-sizing: border-box;
  margin: 0;
  padding: 0;
  border: none;

  &:not([data-scrollbars="true"]) {
    /* hide scrollbars */
    -ms-overflow-style: none; /* IE, old Edge */
    scrollbar-width: none; /* Firefox */

    /* Chrome, Safari, Opera, Edge */
    &::-webkit-scrollbar {
      display: none;
    }
  }
}

.scoped-reset {
  @include reset();

  * {
    @include reset();
  }
}

I noticed that ::before and ::after elements had been omitted (the universal selector * does not select them) and would therefore still have the default box-sizing behavior. A minor issue, but I felt the urge to set things right and added them.

.scoped-reset {
  @include reset();

  *,
  ::before,
  ::after {
    @include reset();
  }
}

Imagine my surprise when after this innocuous addition some elements in the app started to show visible scrollbars.
And right enough during runtime the scrollbar-hiding rule block was not applied anymore.

Act II - Understanding the Problem

Looking at the resulting CSS reveals some selectors that are nonsensical because they could never match anything, but the real trouble with them is that they are invalid; and because they are used in a selector list the whole rule block is ignored.

.scoped-reset *:not([data-scrollbars="true"]),
.scoped-reset ::before:not([data-scrollbars="true"]),
.scoped-reset ::after:not([data-scrollbars="true"]) {
  -ms-overflow-style: none;
  scrollbar-width: none;
}

.scoped-reset *:not([data-scrollbars="true"])::-webkit-scrollbar,
.scoped-reset ::before:not([data-scrollbars="true"])::-webkit-scrollbar,
.scoped-reset ::after:not([data-scrollbars="true"])::-webkit-scrollbar {
  display: none;
}

What is invalid here are all those selectors that chain additional parts onto pseudo-elements, like ::before:not([data-scrollbars="true"]) or ::before::-webkit-scrollbar or even ::before.foo. A bit of googling revealed that others had discovered this also: stackoverflow, some blog

An invalid selector represents, and therefore matches, nothing. When a selector list contains an invalid selector, the entire style block is ignored, except for the :is() and :where() pseudo-classes that accept forgiving selector lists.
MDN

When writing CSS by hand there is little danger of chaining any selectors onto pseudo-elements; but using SCSS with mixins can easily produce such selectors without us being aware.

Act III - Resolving the Problem

I can see two different approaches to solve this.
The first approach is to wrap the problematic selector parts into a forgiving selector.
The second approach is to refactor the code so that invalid complex selectors do not result.
Let's try both.

Using a Forgiving Selector

Astonishingly it is valid to chain a forgiving selector part onto a pseudo-element, like so: ::before:where(:nonsens).
We could guard the mixin therefore such:

@mixin reset() {
  box-sizing: border-box;
  margin: 0;
  padding: 0;
  border: none;

  &:where(:not([data-scrollbars="true"])) {
    /* Hide scrollbars */
    -ms-overflow-style: none; /* IE, old Edge */
    scrollbar-width: none; /* Firefox */

    /* Chrome, Safari, Opera, Edge */
    &:where(::-webkit-scrollbar) {
      display: none;
    }
  }
}

.scoped-reset {
  @include reset();

  *,
  ::before,
  ::after {
    @include reset();
  }
}

The resulting CSS might be ugly but the selector lists are no longer invalid:

.scoped-reset *:where(:not([data-scrollbars="true"])),
.scoped-reset ::before:where(:not([data-scrollbars="true"])),
.scoped-reset ::after:where(:not([data-scrollbars="true"])) {
  -ms-overflow-style: none;
  scrollbar-width: none;
}

.scoped-reset *:where(:not([data-scrollbars="true"])):where(::-webkit-scrollbar),
.scoped-reset ::before:where(:not([data-scrollbars="true"])):where(::-webkit-scrollbar),
.scoped-reset ::after:where(:not([data-scrollbars="true"])):where(::-webkit-scrollbar) {
  display: none;
}

It is nice to know that this escape hatch works, but I would probably prefer the second approach: refactor the code to not produce invalid selectors.

Refactoring the Code

It could be refactored in several differenty ways; one way that seems sensible to me is to split out the scrollbar-hiding rules into a separate mixin:

@mixin reset() {
  box-sizing: border-box;
  margin: 0;
  padding: 0;
  border: none;
}

@mixin hide-scrollbars() {
  &:not([data-scrollbars="true"]) {
    -ms-overflow-style: none; /* IE, old Edge */
    scrollbar-width: none; /* Firefox */

    /* Chrome, Safari, Opera, Edge */
    &::-webkit-scrollbar {
      display: none;
    }
  }
}

.scoped-reset {
  @include reset();
  @include hide-scrollbars();

  * {
    @include hide-scrollbars();
  }

  *,
  ::before,
  ::after {
    @include reset();
  }
}

This feels right to me.

End

I learned a great deal through the bug I caused. And I will certainly be more cautious with my mixins in the future. It is good to know that :is() and :where() can be used as secret weapons in case I run into a similar problem without an obvious path to resolve the issue through refactoring.

a clean approach to DOM event cancellation

Martin — Sun, 02 Apr 2023 19:37:03 +0000

tldr: don't .stopPropagation() - mark handled instead with .preventDefault() - check e.defaultPrevented on the first line of any well behaved event handler

motivation

If you have a chain of event handlers on different levels in the DOM acting on the same event type but you only want to execute one of them each time the event fires, you need some form of event cancellation.

A well known real world use-case is the Esc key to close an open dropdown, a popup, or a modal dialog.
If we want to close an open dropdown that is contained in an open dialog, we wouldn't expect both to close when we hit Esc.

The innermost handler would handle the key and cancel the event.

Many blog articles on the web or answers on stackoverflow will recommend stopPropagation.
But I advise against it; as it severely interferes with and breaks a mechanism other parts of the UI rely on: that all bubbling UI events will reach the root (and that -in general- parent elements can observe events originating in child elements).

who owns the event?

Years ago I authored a small dropdown-menu component for an application maintained by a team of developers. The menu would close if any clicks outside its own visual tree would occur.
Some day the closing behavior got erratic. It turned out that another developer had handled mouse click events in one of his components and had cancelled each handled click with stopPropagation.
"Well, my component handled the event already; and therefore no other part of the code needs to know about it." was the reasoning behind it.
This assumption is flawed. The menu component has a valid interest to know of each and every click that occurred anywhere in the UI.
I even suspect that we can never with certainty claim that we absolutely understand how large the valid audience for any event really is, now and in the future of our application. In consequence we should never stop the propagation of bubbling events.
We should rather treat them as shared resources, owned collectively.

a solution

The DOM is not the only technology that has the concept of bubbling events.
WPF and Silverlight solved it by having a handled flag on all event arguments for bubbling events. Propagation cannot be stopped. An event can only be marked as handled, and by default event handlers further up the chain will only be invoked for unhandled events; any handler can opt-in to be also invoked for handled events.

Well, we have something quite similar in the DOM: we have the defaultPrevented flag. We now only have to ensure our event handlers are well behaved and check the flag before acting on the event.

a testimonial

I used this approach in several projects and found that it helps in keeping DOM event handling involving cancellation simple and clear.
In scenarios with deep nesting, where event handling is distributed over many different components that need to play nicely together, adhering to the self-imposed rule of honoring defaultPrevented and calling .preventDefault() has proven effective to avoid bugs like those mentioned earlier (Esc key closing more than one element at a time).

implementation

The approach per se is completely framework agnostic.
When using this approach all event handlers would need to answer two questions:

What does it need to handle? Either only unhandled events (which would always check defaultPrevented before acting) or all events (which doesn't need to care)
After acting on the event, can the event be considered dealt with? If this is the case .preventDefault() needs to be called.

One example that only cares for unhandled events, and marks them handled:

<div
  onKeyDown={(e) => {
    if (e.defaultPrevented) return;

    if (e.key === "Escape") {
      close();
      e.preventDefault();
    }
  }}
/>

And one that cares for all events, but doesn't change the state of the event:

const handleRootClick = (e) => {
  if (!popupRef.contains(e.target)) closePopup();
};
document.addEventListener("click", handleRootClick);

why not capture?

One might propose to use the capture phase in the scenario described earlier, where a menu component needs to listen for all click events on the root element.
Well, I used this as a workaround in the past, when misbehaving components are outside my control, e.g. because third-party libs are used.
But I don't consider it a solution to the general event cancellation conundrum. Event handlers in the capturing phase could stopPropagation() the same way they can interfere in the bubbling phase.

Satan's Pissbucket - A React Anti Pattern and its Remedy

Martin — Fri, 09 Sep 2022 12:27:55 +0000

Everyone who writes code regularly will sometimes produce suboptimal results. Lack of sleep, naive assumptions about the platform, being oblivious of the existence of a crucial feature, or for one of a hundred other reasons. I am fully aware that I have certainly done so in the past, and that others had to clean up after me.

Recently I encountered a remarkably ugly pattern in a react project I am involved in. In this article I will discuss 1.) the pattern, 2.) why I think it is an anti pattern, and 3.) how I will go about replacing it with something else.

This article is not intended to deride the developer who implemented it. It is meant to be educational, entertaining, and maybe a bit cathartic - because this time I will be the one who has to clean it up.

the pattern

Let's first share it without any prior explanation. So you can re-experience what I encountered in our source code lurking around a bend.

<CreateProductCollectionDialog productID={id}>
  {(openCreateProductCollection) => (
    <AddToProductCollectionDialog
      productID={id}
      openCreateProductCollectionDialog={openCreateProductCollection}
    >
      {(openAddToProductCollection) => (
        <EditProductCollectionDialog productID={id}>
          {(openEditProductCollection) => (
            <ProductItemMenu>
              <Button onClick={openCreateProductCollection}>
                {"Start new product collection"}
              </Button>
              <Button onClick={openAddToProductCollection}>
                {"Add to product collection"}
              </Button>
              <Button onClick={openEditProductCollection}>
                {"Edit product collection"}
              </Button>
            </ProductItemMenu>
          )}
        </EditProductCollectionDialog>
      )}
    </AddToProductCollectionDialog>
  )}
</CreateProductCollectionDialog>

The code snippet is not embellished. I could have added the <EditProductItemDialog> and <DeleteProductItemDialog> to the nesting for dramatic effect, but those two dialogs were implemented later, thankfully breaking with the nested pattern and using a differen approach (more of that later).

So what is it supposed to do?
Why are there three dialogs nested inside each other?
Why are the buttons that are supposed to open those dialogs nested inside there at the deepest point?
Why is each nested child dialog wrapped in a function?

Imagine some product info is displayed on some admin UI, a menu offers different actions to change or interact with the displayed product:

create a new collection and add as first item,
add it to some existing collection,
if the item is currently part of one or more collections, edit those collections

Each of those actions will open its own dialog which contains the corresponding form.
The menu entries will need to have a callback to open their respective dialog.
So what each of those dialog components is doing is that it sets up its own required infrastructure:

it has a boolean state to control whether the dialog is open

  const [isOpen, setIsOpen] = useState(false);

it has some markup to conditionally render the actual popup into the DOM

  <>
    {isOpen && (
      <Popup>
        <EditProductForm productID={productID} />
      </Popup>
    )}
  </>

it is mounted as part of the logical component tree (so the state persists and doesn't vanish when the actual popup closes)
it requires the children prop to be a function, and will call it, providing the callback to open the dialog as the only function parameter

  <>{children(() => setIsOpen(true))}</>

it will unconditionally render the children into the DOM, and is prepared to render the actual dialog popup into the DOM depending on the isOpen state

This pattern actually works as intended, and if this was the only way to supply a callback from one component to another it would be acceptable - by necessity. That's probably the reasoning the original author followed.

And notice that the <AddToProductCollectionDialog> even has access to the openCreateProductCollection callback and can therefore trigger the <CreateProductCollectionDialog> if needed.

Here is one (severely abridged) implementation as a working example for the interested reader (you can skip this if you understood the gist of it from the small bullet point list above):

import React, { useState, FC, ReactNode } from "react";
import { CreateProductCollectionForm } from "./ProductCollectionForms";
import { Popup } from "./Popup";
import { ID } from "./productAPI";

interface Props {
  productID: ID;
  children: (openDialog: () => void) => ReactNode;
}

export const CreateProductCollectionDialog: FC<Props> = ({
  productID,
  children,
}) => {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <>
      {children(() => setIsOpen(true))}
      {isOpen && (
        <Popup onClose={() => setIsOpen(false)}>
          <CreateProductCollectionForm productID={productID} />
        </Popup>
      )}
    </>
  );
};

So in the end the whole fantastic cascade of nested dialog components will render the product item menu into the DOM, with its buttons wired up to their corresponding "hidden" dialog infrastructure, ready to be called.

<ProductItemMenu>
  <Button onClick={openCreateProductCollection}>
    {"Start new product collection"}
  </Button>
  <Button onClick={openAddToProductCollection}>
    {"Add to product collection"}
  </Button>
  <Button onClick={openEditProductCollection}>
    {"Edit product collection"}
  </Button>
</ProductItemMenu>

I could even admire it, if the pattern wasn't so ridiculously cumbersome.

what's wrong with it?

Let's keep this short:

it is needlessly complicated
the nesting is confusing
it does not scale well
the callback is only available to children
the nesting order seems relevant, even when it isn't
it forces the use of a wrapper function around the children
it seemingly interferes with the layout: imagine ProductItemMenu needs to be a flexbox child to be positioned correctly. So wrapping it seems problematic and forces the next developer to unravel the whole nesting chain to find out that -after all- it's still a flexbox child in the resulting DOM.

And finally: there is a much simpler solution.

A Remedy

This whole mess started with the necessity to supply a callback from one component to another.
What would you do if you needed a callback to set focus() to an <input>? Simple, you would use a ref.

Well, you can do the same thing with any of your custom components. It needs to be wrapped with forwardRef so the ref doesn't get lost (doc).
I wrote an article covering that feature.
Internally the forwarded ref is then wired to an object (with useImperativeHandle doc); to which you can add any callback you can think of; thereby providing access to change state.

An improved dialog could be implemented thus:

import { useState, forwardRef, useImperativeHandle } from "react";
import type { ForwardedRef, ReactNode } from "react";
import { Popup } from "./Popup";

export interface DialogProps {
  children?: ReactNode;
}

export interface DialogAPI {
  open: () => void;
  close: () => void;
}

export const Dialog = forwardRef(
  ({ children }: DialogProps, ref: ForwardedRef<DialogAPI>) => {
    const [isOpen, setIsOpen] = useState(false);
    const open = () => setIsOpen(true);
    const close = () => setIsOpen(false);
    useImperativeHandle(ref, (): DialogAPI => ({ open, close }), []);

    return isOpen && <Popup onClose={close}>{children}</Popup>;
  }
);

It would be used thus:

import { Dialog, DialogAPI } from './Dialog';

// ...

const dialog = useRef<DialogAPI>();

<>
  <Button onClick={() => dialog.current.open()}>
    {"Edit product"}
  </Button>
  <Dialog ref={dialog}>
    <ProductForm
      productID={id}
      onSubmitSuccess={() => dialog.current.close()}
      onCancel={() => dialog.current.close()}
    />
  </Dialog>
</>

Now the button, the edit form, and the dialog could all be moved into one combined component <EditProduct productID={id} />, easily allowing to add this functionality to different places in the UI with one line of code, complete with the whole dialog popup infrastructure.

Let's see how the code section I showed you in the beginning would look when we change the dialog pattern to the new one.

<ProductItemMenu>
  <CreateProductCollection productID={id} />
  <AddToProductCollection productID={id} />
  <EditProductCollection productID={id} />
</ProductItemMenu>

The nesting is gone and the dialog infrastructure moved into the specialized buttons.

Remember that the <AddToProductCollectionDialog> must have the possibility to trigger the <CreateProductCollectionDialog> if needed?
This is even easier now since it can just import <CreateProductCollection> and render it somewhere in its form.

To me this is much clearer. The nesting is gone. The unholy entanglement is resolved. Each part of the functionality is clearly separated. New functionality can be added without interfering with the other parts, or the necessity to understand each and every of the existing dialogs and edit forms.

My Good Friend Flexbox

Martin — Sun, 10 Jul 2022 15:15:13 +0000

This article is neither an introduction to the flexbox nor an exhaustive treatise of all its features.
Instead I attempt to shine a spotlight on some selected flexbox features that are often overlooked.

The Swiss Army Knife of CSS Layout

I frequently resort to the flexbox for layouting. It comes with a wealth of features that allows us to faithfully transfer elaborate UI designs into working code.

If I am in the middle of writing some beautiful CSS and stop for a moment because I can't remember the exact property name I usually visit A Complete Guide to Flexbox and lookup flexbox properties there.
But knowing all the properties is only half the battle, the other half is knowing what they can accomplish, and it is in this second half where some marvelous discoveries can be made.
An article that made me aware of some of the not-so-obvious parts of the flexbox is 11 things I learned reading the flexbox spec.
Others I discovered while working with the flex, investigated odd behavior, or stumbled upon on mdn while on some unrelated errand.

And it is in the vein of this 11 things article that I attempt to shine a spotlight on some selected flexbox features here that I feel are often overlooked or a bit esoteric.

Control the Split

We all know how to bring all elements to the left, or all to the right. We can stack them all at the top, or all at the bottom.
But what if there needs to be a split? Say 3 to the left and 2 to the right?

And multiple splits? Say one to the left, one to the right, and the rest in the middle?

Use margin: auto to control where the split shall be. This is special flexbox behavior. The auto margin gets all the remaining space; if more than one flex child has auto margin it is distributed equally among them.

The two splits shown in the image above can be created like this:

<div class="container">
  <div class="item" style="margin-right: auto;"></div>
  <div class="item"></div>
  <div class="item"></div>
  <div class="item"></div>
  <div class="item" style="margin-left: auto;"></div>
</div>

Before I knew about the special meaning of margin: auto I usually used flex-grow on one or more of the flex children as a means to push the items apart.
I now consider auto margin the proper way.

Multiline Layouts

You can create intricate multiline layouts by deliberately pushing items onto separate lines.
Use calculated margins to control how many items should end up on a single line, pushing later items to the next line.

a flexbox honeycomb layout

A honeycomb layout for example could be achieved thus:

<div class="container">
  <div class="item first of-2"></div>
  <div class="item last of-2"></div>
  <div class="item first of-3"></div>
  <div class="item"></div>
  <div class="item last of-3"></div>
  <div class="item first of-2"></div>
  <div class="item last of-2"></div>
</div>

.container {
  display: flex;
  flex-wrap: wrap;
  gap: 10px;
}
.item {
  width: 20px;
  height: 20px;
  background: #dddddd;
}
/*                         width of items   width of gaps      */
.of-1 { --indent: calc((100% - (1 * 20px) - (0 * 10px)) * 0.5); }
.of-2 { --indent: calc((100% - (2 * 20px) - (1 * 10px)) * 0.5); }
.of-3 { --indent: calc((100% - (3 * 20px) - (2 * 10px)) * 0.5); }
.first { margin-left: var(--indent); }
.last { margin-right: var(--indent); }

a flexbox pyramid layout

And a pyramid could use the same CSS and have such markup:

<div class="container">
  <div class="item first last of-1"></div>
  <div class="item first of-2"></div>
  <div class="item last of-2"></div>
  <div class="item first of-3"></div>
  <div class="item"></div>
  <div class="item last of-3"></div>
</div>

wrapping flexbox children without breaking the parent-child nesting

Some time ago I needed to wrap some DOM element in a simple <div> (to hook into bubbling DOM events; and I couldn't just addEventListener to the wrapped element for reasons). But I didn't want to break any layout that relies on direct parent-child nesting which is the case with the flexbox layout.
My solution was to apply display: contents to the wrapper (MDN).
This causes the CSS layout to be rendered as if the wrapper didn't exist and as if the wrapped elements were direct children of the original parent.

Both <p> elements are treated as flexbox children here:

<div style="display: flex">
  <div style="display: contents">
    <p style="flex-grow: 1"></p>
  </div>
  <p style="flex-grow: 1"></p>
</div>

flex: none - all the SVGs!

By default flex children are "squishy". And it happend more than once that I used flex to align an icon and a corresponding text on the same line, only to discover some time later that long texts will squish the icon out of shape.
I now have it as a personal rule of thumb to always set flex: none to flex items that are supposed to have a fixed width, i.e. that are not supposed to grow / shrink together with their surrounding flex container.
So in my experience items usually fall in one of two categories: fixed size items and responsive size items.
It probably is a good idea to just be explicit in the style rules for flex items and set either flex: none or flex: auto; and thereby declaring in which category they belong.

mind the gap

The flexbox has a gap property (and more specific row-gap / column-gap) so we no longer need to set margins on the items.
This eliminates the need to have any special rule for the first or the last child.
Before the gap property was fully supported it was often necessary to apply a margin-left to all children except the first; or to apply a margin-right to all children except the last.

Bits and Pieces

I felt the following things are probably not immensely useful. But I don't want to keep them secret either.

special handling of stacking context

A flex child with any z-index set will establish a stacking context. Remember that for any other element setting position to absolute or relative is needed in addition to the z-index to establish a new stacking context.

special handling of visibility: collapse

If a few months ago I would have had to descibe the different effects on layout the three possible visibility values visible, hidden, collapse would have on any given element, I would have got it wrong. I was so sure of it: that collapse would free up the space and allow other elements to take up the place of the collapsed element.
Well, that is simply not true. The values hidden and collapse both have the same effect generally. I was astonished to find this out, read for yourself on mdn.

Strangely but luckily the behavior of flex children is special: here the value actually acts in accordance with the expectations of any sane person.
A flex child with visibility: collapse frees up its space so other elements can take it up.
Addendum: In Chrome (and browsers that use the same engine) this doesn't work. There is a bug that hidden and collapse on flex children currently behave the old way, i.e. not freeing up space in the collapse case. It was opened 2014 and is still open in 2024 so I don't expect this to get fixed anytime soon.
Addendum 2: There was an update on the bug on Jun 3, 2025 08:49PM so it might be fixed and closed soon

IE11 and the flexbox

If you find yourself in a situation when you have to solve a flexbox related layout bug for IE11, you might want to have a look at this collection of known issues and workarounds which helped me a great deal in the past.

reminder: there is an inline variant

There is also a display: inline-flex variant. Towards its surroundings it acts as any inline element, towards its children it is a flexbox.
I sometimes need this if I need to place a flexbox inside a <table> cell so the box itself can be aligned left, center, or right like any text cell content.

modal.open() - Imperative Component API in React

Martin — Sun, 06 Feb 2022 15:15:55 +0000

Well, here is the gist of this article:
Your custom React components can have an imperative API of your own choosing. And it's even quite simple to implement.
The feature is supported (for function components) by React since v16.8 (The One With Hooks) but I have a hunch that knowledge about its existence is not widespread.
But let's start at the beginning.

declarative vs imperative - props vs ref

React components usually accept a bunch of properties: the props.
Those props form the declarative API of the component; and for most use-cases this is perfectly sufficient.

But from time to time we encounter some component or other that can be switched on and off; or has some other kind of triggerable functionality that would fit more naturally in an imperative API.

If we don't know about imperative APIs we are forced to pull its state up into the parent, although we would rather like the component to encapsulate and control its own state.

const [isModalOpen, setIsModalOpen] = useState(false);

<button onClick={() => setIsModalOpen(true)}>Open</button>
<Modal isOpen={isModalOpen} />

It seems like every <Modal /> component I have ever seen is built that way.

Let's look for an alternative.

When using an imperative API we would obtain a reference to the component instance, and call any exposed API function on that instance.

const modal = useRef();

<button onClick={() => modal.current.open()}>Open</button>
<Modal ref={modal} />

But to make this actually work requires the implementation of <Modal /> to explicitly allow this scenario.
Ever wondered what forwardRef and useImperativeHandle are good for?

forwardRef and useImperativeHandle

You cannot just set ref on a component like you would on a simple <div>. React removes it from the props (same goes for key btw), and the implementation of the component would not be able to retrieve it via props.ref.
A component can be wrapped with forwardRef to allow the ref to be tunnelled through; the ref would then be available to the implementation as a second argument to the render function (first and usually the only argument to the render function is props). So it is a deliberate choice by the component author to allow the usage of ref.

const Modal = forwardRef((props, ref) => {
  const [isOpen, setIsOpen] = useState(false);
  return isOpen && <div className="modal">{props.children}</div>;
});

We can now attach an object to ref.current that exposes a curated selection of functions to open, close, or toggle our modal. But we really don't want to create and attach that object every time the modal is rendered. If possible this should only be created once during the lifetime of our modal. And that is exactly what the little known hook useImperativeHandle does.

const Modal = forwardRef((props, ref) => {
  const [isOpen, setIsOpen] = useState(false);
  useImperativeHandle(
    ref,
    () => ({
      open: () => setIsOpen(true),
      close: () => setIsOpen(false),
      toggle: () => setIsOpen((_) => !_),
    }),
    []
  );
  return isOpen && <div className="modal">{props.children}</div>;
});

That's all we have to do to create and support an imperative API for our component.
We now offer functions for opening and closing the modal, but we can still accept declarative props for things like headerContent, bodyContent, footerContent, and so forth (honestly I would utilize the children for anything considered content, but that's not today's topic).

But could we also allow both?

controlled and uncontrolled

An <input> element can be use as both; as a controlled element and as an uncontrolled element; depending on whether the value state is managed by the parent or by the child.

Could we implement the modal to allow both usages? We could check whether an isOpen state was provided by the parent and treat this as the controlled scenario, and as the uncontrolled scenario otherwise. In the controlled scenario the external state is used to decide how to render; in the uncontrolled scenario the internal state is used.

const Modal = forwardRef((props, ref) => {
  const isUncontrolled = props.isOpen === undefined;
  const [isOpen, setIsOpen] = useState(false);
  useImperativeHandle(
    ref,
    () => ({
      open: () => setIsOpen(true),
      close: () => setIsOpen(false),
      toggle: () => setIsOpen((_) => !_),
    }),
    []
  );
  const showModal =
    (isUncontrolled && isOpen) || (!isUncontrolled && props.isOpen);
  return showModal && <div className="modal">{props.children}</div>;
});

sharing state with the parent

I'm not talking about lifting the state into the parent. I'm talking about managing the state inside the component but allowing the parent read-access. And most importantly: allowing read-access with the added benefit of controlling re-renders when the state changes.

We can decide to publish our internal state together with the API functions as a plain old property on the API object.
The useImperativeHandle hook supports a dependency array that allows us to re-create the API object when relevant portions of our internal state change.

const Modal = forwardRef((props, ref) => {
  const [isOpen, setIsOpen] = useState(false);
  useImperativeHandle(
    ref,
    () => ({
      open: () => setIsOpen(true),
      close: () => setIsOpen(false),
      toggle: () => setIsOpen((_) => !_),
      isOpen,
    }),
    [isOpen]
  );
  return isOpen && <div className="modal">{props.children}</div>;
});

If the parent of our component utilizes the useRef hook, any changes to ref.current will not trigger a re-render and the parent might see a stale isOpen state.

const modal = useRef();

// this info will be stale
{`The modal is ${modal.current?.isOpen ? 'open' : 'closed'}`}
<button onClick={() => modal.current.open()}>Open</button>
<Modal ref={modal} />

But the useImperativeHandle hook also supports callback-refs (just a function that is assigned to the ref property; the callback is called when the ref changes, and we can store the reference, for example in a useState). The setter function of a useState is perfectly fine to be used with a callback-ref, triggering a state change and therefore a re-render whenever the referenced object changes.

const [modal, setModal] = useState(null);

// this info will never be stale
{`The modal is ${modal?.isOpen ? 'open' : 'closed'}`}
<button onClick={() => modal.open()}>Open</button>
<Modal ref={setModal} />

Notice that when we use a useState instead of a useRef the access slightly changes: modal.open() instead of modal.current.open() and <Modal ref={setModal} /> instead of <Modal ref={modal} />.

Modals, Dropdowns, Accordions, and the World

What types of components would benefit from an imperative API? From the top of my head I would say any component that needs to be able to be toggled between open and closed states; like Modals, Dropdowns, and Accordions.

But also anything with a very complex state (where lifting up the state into the parent is a veritable nightmare).
Imagine a nice re-usable and integratable <Worldmap /> component, designed to be extendable with custom functionality, and only your imagination is the limit to what you can do. Say it supports an onClick with some useful event args like { longitude, latitude } corresponding to your click. Would you want to implement setting a pin where you clicked? Or a context menu that allows you all sorts of things for the clicked location: finding the nearest airport, calculating a route, or zooming in? For extendability and customizability an imperative API would be a boon.

<Worldmap
  ref={map}
  onClick={(position /*{ longitude, latitude }*/) =>
    showMenu([
      {
        text: "Set pin",
        action: () => map.current.addMarker(position),
      },
      {
        text: "Find airport",
        action: () => geoService.findAirport(position),
      },
      {
        text: "Show route",
        action: () => geoService.findRoute(position),
      },
      {
        text: "Zoom in",
        action: () => map.current.zoom({ position, zoom: 2.5 }),
      },
    ])
  }
/>

I really hope this feature would get more attention. I believe we would see components with better dev experience as a result.

React Dark Magic - Devour your Children

Martin — Thu, 30 Dec 2021 21:41:29 +0000

For most use cases we can write simple idiomatic React code to get the job done. And I assume we all agree that that's the preferred way to write our applications. Sometimes we need to evaluate several approaches before we can settle for the one we deem most fitting. Words like clean, clear, or elegant come to mind.

But what can we do when we exhausted all of the idiomatic approaches without finding a solution? When we are at our wits' end? When we relentlessly racked our brains - Alas! in vain.

Well, then we have to consider the unorthodox solutions, even if our first reaction was repulsion. If you are open minded enough accompany me and let us explore some React dark magic in the following paragraphs.

Real-life use cases

When the Parent needs to know if a Child rendered null

Recently user markdalgleish posted an interesting question on Twitter:

// Detect dark theme var iframe = document.getElementById('tweet-1471007400647790595-503'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1471007400647790595&theme=dark" }

Given the following JSX:
<Parent>
 <Child />
</Parent>
Is there any way for Parent to know if Child rendered null? AFAIK it's not possible, but I'm hoping I'm wrong.

And he's right; with regular idiomatic React the parent can't know or respond to the render output of the child. And the reply from dan_abramov and subsequent posts shed some light on why this is not possible. In short: re-rendering of a child should not necessitate re-rendering of the parent.
Why do we need to know whether the child rendered null in the first place? Mark explains:

I'm wrapping each child in a View that applies spacing between siblings.

...and the spacing needs to be zero when the child produced no visible content.

The situation is peculiar: it is React Native, therefore it can't be solved with CSS wizardry (at least that's what I gather from the replies in the Twitter thread, I have no react-native experience myself). So no flexbox or grid with a neat gap, no margin-top: 10px that gets zeroed on the :first-child, and no use of :empty on the wrapper to erase the margins, as pseudo-classes are not supported by react-native StyleSheets:

[...] you do not have access to pseudo-classes like :hover, :active, etc.

An unorthodox solution

Well, to be blunt, we can just explicitly call the child's render function and inspect the result. And here is an important thing about this outrageous proposal: we can even do so without breaking any written or unwritten contract with the framework. Yes, we can actually write correct code, quite unusual admittedly, but correct.

I will be perfectly honest with you: I only considered function-based components here; class-based components are completely obsolete since React v16.8, which was released nearly three years ago while I'm writing this. So I think any consideration for class-based components would be a waste of time.

So why do I propose explicitly calling a child's render function from within the parent's render function doesn't break the framework?
Because technically we can consider any valid function-based component also a valid custom hook. That's why!

Components are hooks, Strawberries are nuts

What is a custom hook?

any plain synchronous JavaScript function
that may have any number of arguments
that may internally call hooks (a hook is only really a hook if it uses other hooks, but that's not relevant here)
that may return anything, even jsx elements to be used by the caller

What is a function-based component?

any plain synchronous JavaScript function
that accepts a props argument
that may internally call hooks
that returns either bool, null, undefined, empty array, single jsx element, or array of jsx elements

So a component is really just a special case of a custom hook. Namely one that returns jsx.
Ergo we can just treat the component as a hook, as long as we adhere to the rules of hooks when doing so.
Doing so will fuse the child's content with the parent, and from the perspective of the React framework the child ceases to be recognized as a separate level in the logical component tree. The component boundary between parent and child will be lost.
Which in a way solved the issue dan_abramov mentioned: that re-rendering of a child should not necessitate re-rendering of the parent. They are fused together.

Adhering to the rules of hooks forces us to do things a certain way:

We need to call the render function unconditionally.
And what would it mean if the child type changes during the life time of our parent? It would mean that we potetially violate the rules of hooks: we cannot know which hooks are called internally, or what number of hooks was called, it is a blackbox. Well, it means the life time of our parent is coupled to the child type: when the child type changes the parent type must be re-defined.

Ok, let's do it!
If we now try to write a wrapper that accepts any arbitrary single child, checks if any content is rendered, and itself returns null if no child content is produced, we could do it thus:

// <VanishingWrapper> renders null
// if child component renders no elements.
// usage example:
<VanishingWrapper style={{ margin: '10px' }}>
  <SomeChild foo={bar}>
    <NestedContent />
  </SomeChild>
</VanishingWrapper>

import React, { useMemo } from 'react';

const VanishingWrapper = ({ style, children }) => {
    let child = {};
    try {
        child = React.Children.only(children);
    } catch (exception) {
        console.warn(
            'VanishingWrapper accepts only one child element'
        );
    }
    const DynamicComponent = useMemo(
        () => createDynamicComponent(child.type),
        [child.type]
    );
    return (
        <DynamicComponent style={style} childProps={child.props} />
    );
};

const createDynamicComponent = (type) => {
    if (typeof type === 'function')
    {
        const useChildContent = type; // treat as a hook
        const DynamicComponent = ({ childProps, ...props }) => {
            const content = useChildContent(childProps);
            return isVisibleContent(content) ? (
                <div {...props}>{content}</div>
            ) : null;
        };
        return DynamicComponent;
    }
    else if (typeof type === 'string')
    {
        const SimpleComponent = ({ childProps, ...props }) => {
            const content = React.createElement(type, childProps);
            return <div {...props}>{content}</div>;
        };
        return SimpleComponent;
    }
    else return () => null;
};

const isVisibleContent = (content) => {
    // content ignored by react and therefore not visible:
    // bool, null, undefined, or empty array
    return !(
        typeof content === 'boolean' ||
        content === null ||
        content === undefined ||
        (Array.isArray(content) && content.length === 0 )
    );
};

export { VanishingWrapper };

I tried it out and it worked as expected. In the end it didn't feel that outlandish anymore.
What do you think?

But we can have a quick look at another use case in the next paragraph.

Replace the top-level node of a third-party component

User evolon posted his conundrum on Stackoverflow some time ago. (And it was this question and the answer to it that made me first aware of the existence of this rather unorthodox approach.)
Imagine you need to wrap a third-party component and the resulting DOM structure now has a redundant, undesired node. Assume there are valid and pressing reasons to get rid of this node.

<div className="wrapper">
  <ThirdPartyComponent />
</div>

yields

<div class="wrapper">
  <div>
    <span>...</span>
  </div>
</div>

but we need

<div class="wrapper">
  <span>...</span>
</div>

How do you replace the top-level node when the component stems from a third-party package and thus you cannot just change the implementation? How do you achieve the desired DOM structure?

As in the first use case we can safely treat our third-party component as a custom hook. The same reasoning applies. It is even easier because the type of the child is not dynamic.
We therefore just call the render function as if it was a custom hook, get the nested content and inject it into our own top-level wrapper:

import React from 'react';
import {
    ThirdPartyComponent as useThirdPartyContent
} from 'third-party';

const Wrapper = () => {
    const thirdPartyContent = useThirdPartyContent();
    const nestedContent = thirdPartyContent.props.children;
    return (<div className="wrapper">{nestedContent}</div>);
};

export { Wrapper };

This solution follows the answer user AKX gave on Stackoverflow. Please be aware of his words of caution if you decide to use this approach. If the implementation of the third-party component changes in the future your wrapper might break.

Conclusion or TLDR

A child's render function can be called directly and its result can be tampered with to achieve a desired outcome, when all other -- more orthodox / more idiomatic-react -- approaches are impracticable (and exhausted).
Technically a render function can be treated as a custom hook that returns jsx. Rules of hooks apply.
Doing so will fuse the child's content with the parent, and from the perspective of the React framework the child ceases to be recognized as a separate level in the logical component tree.
This approach is technically correct, it is unusual and unexpected though; therefore at least violates the "principle of least surprise". This is probably one of those cases where the code should be accompanied by comments explaining the peculiarities (and a link to this blog article might greatly help the future maintenance developer).

Just a silly rhyme

probably by Shakespeare

the scholar and the fool both jeer
at any boldly new idea
not written in your wisest books
yet true that components are hooks
the scholar laughs and clueless struts
pretensions rich, not knowing much
not least that strawberries are nuts

A Concise Pattern for Container-and-Content Elements in React

Martin — Thu, 16 Sep 2021 11:43:19 +0000

Imagine you have to develop a Grid component with React. And any arbitrary JSX element can be used as content for your Grid.
How do you specify which element goes into which grid cell?

A common approach is to provide wrapper elements for rows and columns; which often produces lamentably verbose and cluttered markup; and soon clarity goes out the window.

what we want to avoid: rampant verbosity

<Grid>
  <Grid.Row>

    {/* cell top left */}
    <Grid.Column>
      <Red />
    </Grid.Column>

    {/* empty cell top center */}
    <Grid.Column />

    {/* cell top right */}
    <Grid.Column>
      <Green />
    </Grid.Column>

  </Grid.Row>
  <Grid.Row>

    {/* empty cell bottom left */}
    <Grid.Column />

    {/* cell bottom center */}
    <Grid.Column>
      <Blue />
    </Grid.Column>

    {/* cell bottom right */}
    <Grid.Column>
      <Pink />
    </Grid.Column>

  </Grid.Row>
</Grid>

Wouldn't it be nice if we could just tack the necessairy row/column information onto the content element? And get rid of all those wrapper elements?
Actually we can.
Since React allows us to add any properties we fancy to any element - regardless of whether those properties are ever used by the component's implementation or not - we can in principle just set row and column on the content directly.

what we seek: divine neatness

<Grid>
  <Red   row={1} column={1} />
  <Green row={1} column={3} />
  <Blue  row={2} column={2} />
  <Pink  row={2} column={3} />
</Grid>

Two issues arise:

property names could clash if we ever tried to place an element in our grid that has its own property of the name row or column
in many projects either a linter or the TypeScript compiler would vehemently protest, and would rightfully state that neither row nor column are part of the component signature

Luckily we can solve all issues:

we can add a GUID to the property name to make it unique and thus prevent name clashes
we can provide a utility function so no one ever has to type out the GUID when setting the property
we can use the spread operator syntax to apply the tuple of property name and value
linters and the TypeScript compiler deem spread properties acceptable

Our revised markup would look like this:

<Grid>
  <Red   {...Grid.row(1)} {...Grid.column(1)} />
  <Green {...Grid.row(1)} {...Grid.column(3)} />
  <Blue  {...Grid.row(2)} {...Grid.column(2)} />
  <Pink  {...Grid.row(2)} {...Grid.column(3)} />
</Grid>

A working implementation of this Grid component is available on GitHub.

With this idea in mind we can formulate a general Attached Properties pattern:

Whenever a component...

has the role of a container

that accepts any arbitrary JSX elements as content

and needs additional information associated with content elements

...the additional information can be implemented as Attached Properties (as an alternative to the introduction of dedicated wrapper components).

The pattern therefore has a clearly defined field where it is applicable. It is a useful alternative to wrapper components. It can greatly help in reducing cluttered markup, and help in producing readable code.

Behold the Possibilities!

Obvious applications for the pattern are dedicated layout components - as is the <Grid> we have seen in the first paragraph.
We can picture more specialized layout components like a <DockPanel> or a <React3DViewbox> that would also benefit from the pattern. Or even a generic <Modal> component with header, body, and footer sections. How would they look?

<DockPanel>
    <div {...DockPanel.top()} />
    <div {...DockPanel.left()} />
</DockPanel>

<React3DViewbox>
    <div {...React3DViewbox.coordinates(56, 67, 78)} />
    <div {...React3DViewbox.coordinates(12, 23, 34)} />
    <div {...React3DViewbox.coordinates(100, 100, 0)} />
</React3DViewbox>

<Modal>
    <h2 {...Modal.isHeader()}>
        We use cookies
    </h2>
    <p>
        etc.
    </p>
    <Button>
        View details
    </Button>
    <Button {...Modal.isFooter()}>
        Decline
    </Button>
    <Button {...Modal.isFooter()}>
        Accept
    </Button>
</Modal>

But its applicability is not confined to layout components; it can be used to selectively add behavior to deeply nested content elements, whilst preserving the parent-child structure of your content. You would be reluctant to place a wrapper around a flexbox child, but adding a property to it is fine.

this feels right:

<DropdownButton>
    <p>
        It was a dark and stormy night...
    </p>
    <FancyBorder className="fancy-flexbox">
        <Button>
            Open some flyout
        </Button>
        <Button {...DropdownButton.closeOnClick()}>
            Option #Foo
        </Button>
        <Button {...DropdownButton.closeOnClick()}>
            Option #Bar
        </Button>
        <Button>
            Show more...
        </Button>
    </FancyBorder>
</DropdownButton>

this feels wrong:

<DropdownButton>
    <p>
        It was a dark and stormy night...
    </p>
    <FancyBorder className="fancy-flexbox">
        <Button>
            Open some flyout
        </Button>
        <DropdownButton.CloseOnClick>
            <Button>Option #Foo</Button>
        </DropdownButton.CloseOnClick>
        <DropdownButton.CloseOnClick>
            <Button>Option #Bar</Button>
        </DropdownButton.CloseOnClick>
        <Button>
            Show more...
        </Button>
    </FancyBorder>
</DropdownButton>

A working implementation of this DropdownButton component is available on GitHub. (To be totally honest: the same display: contents mechanism that is used by the DropdownButton implementation applying the Attached Properties pattern to preserve css layout integrity could also be used in an alternative implementation applying the Wrapper pattern that would also preserve css layout integrity. But it would still raise concerns with attentive developers wherever it would be used.)

Implementation

The pattern can be implemented in any vanilla React project. A simple implementation of the Grid component from the first paragraph could look like this:

import React from 'react';

const guid = 'bf1b5a20-ec50-4530-8a10-ae78bdc62e74';
const rowProp = `${guid}_row`;
const colProp = `${guid}_column`;

const Grid = ({ children, rows = 2, columns = 2 }) => (
    <div className={`grid-${columns}-${rows}`}>
        {React.Children.map(children, (child) => {
            const row = (child.props && child.props[rowProp]) || 0;
            const column = (child.props && child.props[colProp]) || 0;
            const placement = `cell-${column}-${row}`;
            return (<div className={placement}>{child}</div>);
        })}
    </div>
);

Grid.row = (x) => ({ [rowProp]: x });
Grid.column = (x) => ({ [colProp]: x });

export { Grid };

There are however some pitfalls and ramifications: How can children be mapped recursively? How deep should the recursion go? What happens with attached properties that are propagated to the children of content elements?

Those questions are addressed in detail in the documentation of react-attached-properties, a tiny library that is intended to make using the Attached Properties pattern even easier and to provide ready-made solutions to circumnavigate potential pitfalls.

Does it Work with TypeScript?

Yes. You can either rely on the TypeScript type inference mechanism to pick up the property setters like Grid.row = (x: number) => ({ [attachedRowID]: x }); so it won't protest at <div {...Grid.row(3)} /> or you can declare the property setters for the container interface IGrid {row(x: number): object;}.
There are examples in the TypeScript section of the documentation.