Philosophy

The higher order components all follow the same three rules. Knowing them is enough to predict how any of them behaves.

They clone, they do not wrap

Each one takes exactly one element and clones it, adding a class and — where the effect needs it — a pointer handler. Nothing is inserted into the DOM, so the child keeps its own place in the layout: it can sit on a grid column, be a flex item, or carry a margin, and none of that changes by decorating it.

tsx
<BorderGlow>
  <Card className="margo-col-span-4"></Card>
</BorderGlow>

The cost of that choice is a requirement on the child: it must be a single element that accepts a className, and the handler the effect needs. A fragment, a string, or two siblings will not do — there would be nothing to clone.

Handlers you already passed are not replaced. The decorator does its work and then calls yours, so adding one never silently disables behaviour that was already there.

tsx
<BackgroundGlow>
  <Card onPointerMove={handlePointerMove}></Card>
</BackgroundGlow>

The effect lives in CSS

The visible part is CSS: a pseudo-element carrying a gradient, or a property applied to the element itself, as the mask of MaskGradientY is. JavaScript only writes coordinates and sizes into custom properties — painting, transitioning and fading are the browser's work.

tsx
event.currentTarget.style.setProperty("--margo-background-glow-x", `${x}px`);
event.currentTarget.style.setProperty("--margo-background-glow-y", `${y}px`);

That is why these components hold no state and trigger no re-render: a pointer that sweeps across a card updates two custom properties per event, and React is never told. It is also why they cost nothing when nobody is interacting with them — the pseudo-element sits at zero opacity and the handler is not firing.

They are decorations, not requirements

Remove one and the child renders exactly as before, minus the effect. Nothing in the layout, in the accessibility tree or in the behaviour of the element depends on the decorator being there, which is what makes them safe to apply late and to drop without a rewrite.

It also means they carry no semantics of their own. An element that needs to announce a state — pressed, selected, busy — must still say so itself; a glow is feedback for a pointer, never information.

Composing them

Because each one only clones its child, nesting two is legitimate: the inner one decorates the element and the outer one decorates the result, which is still that same element.

tsx
<BorderGlow position="right">
  <BackgroundGlow tolerance={0.6}>
    <nav></nav>
  </BackgroundGlow>
</BorderGlow>

Whether it is a good idea is a separate question. Two effects on a small control usually read as two competing highlights; on a large surface — a sidebar, a header — an edge and a fill can complement each other.