Who thinks adding a prefix of $ is the right solution to React complaining about non-DOM props?!

[zackarydev]

I personally hate it.

It's giving me PHP vibes, or Angular.

"Let's just add a new symbol because we don't know how else to solve this" isn't the right approach IMO

<SomeStyledComponent
    $fontSize={fontSize}
    $isWarning={boolean}
    $isFlashing={boolean}

Which is made even more unreadable in the definition of the styled-component:
(granted there's a double ternary which isn't great)

export const SomeStyledComponent = styled.p<SomeProps>`
    color: ${({ $isWarning, $isFlashing  }) =>
        $isFlashing
            ? !$isWarning
                ? ColorPalette.defaultSuccessColor
                : ColorPalette.defaultWarningColor
            : ColorPalette.defaultColor};
    margin: 0;
`;

Maybe my favourite though is:

export const SomeStyledComponent = styled.p<SomeProps>`
    font-size: ${({ $fontSize }) => $fontSize}px;
`;

[quantizor]

The $ prefix for transient props is by design. It provides a simple, zero-config mechanism to prevent custom props from leaking to the DOM — React warns when unknown props are passed to HTML elements.

The alternative before transient props was using .withConfig({ shouldForwardProp }) on every component or wrapping with StyleSheetManager shouldForwardProp={...} globally (e.g. with @emotion/is-prop-valid). The $ convention is opt-in and avoids that boilerplate.