Preact: `fix className normalization` (#2774) causes regression removing some class names

[4cm4k1]

Hi! I think #2774 is causing a regression, which results in some class names, specifically for Material Icons/RMWC, being removed, and some JS functionality seems broken, too(?). I also verified that reverting to v10.5.2 resolves the regression.

Reproduction

Repo (specific commit): https://github.com/4cm4k1/personal-website/tree/2d4d593ba366b85baa33e05819678491897e776c
Deployment (specific commit): https://personal-website-neqqptm34.vercel.app/
Versions:

├── [email protected]
├── [email protected]

Steps to reproduce

1. Checkout repo at 2d4d593ba366b85baa33e05819678491897e776c
2. yarn install
3. yarn dev (exists on prod deployments, too, see above)
4. Check localhost:3000 (or deployment)

Expected Behavior

Material Icons/RMWC class names are outputted and display properly.

Actual Behavior

Material Icons/RMWC class names are omitted, causing improper display and possibly(?) stops JS.

Thank you!!!

[marvinhagemeister]

For anyone looking into this: I was able to narrow it down to a hydration mismatch. The props are correctly set, but they don't end up in the HTML during SSR. https://github.com/preactjs/preact-render-to-string/blob/master/src/index.js#L168-L170 . The hydration mismatch seems to be caused by both class and className ending up as non-enumerable.

Not sure why we end in that situation though.

[4cm4k1]

Potentially related? https://github.com/vercel/next.js/issues/17463

[jackmoore]

I temporarily worked around this issue by replacing className with class for any components being passed to preact-render-to-string

[charrondev]

I ended up just reverting to 10.5.2 in the meantime, which doesn't seem to have the bug. I guess I must not be fully understanding the initial issue, but 10.5.3 introduces a "fix" for classnames in preact/compat, but from what I can see classnames were working in 10.5.2 and are broken in 10.5.3.

[tbgse]

We're noticing an issue that is possibly related as well where our MUI <TextField /> components are not behaving correctly in 10.5.3. It seems like our defaultValue props are not being rendered at all, no matter what we try. Downgrading to 10.5.2 is not an option either because it completely breaks all styling of MUI components.

[marvinhagemeister]

We've just published 10.5.4 which includes a fix for this issue. Can't reproduce it anymore :tada: