Hacker News Reader

Comment by tunesmith | Hacker News Reader

We've heard rumblings that react18 implies the need for major changes in legacy projects. For instance, jest testing suites apparently need to move away from enzyme?

Also, is there something about MUI and react18 that makes styled-components more of a pain? Not sure where I heard that.

View on HN

Regarding styled-components and many similar CSS-in-JS libraries, I don't think there are any breaking changes currently with React 18, but it does seem like the writing is on the wall that React intends to not support libraries that inject styles into <style> tags, or at least has some specific rules these libraries need to follow to avoid performance problems. See this discussion: https://github.com/reactwg/react-18/discussions/110

I wouldn't say we're planning to not support them. They work with React 18. If they move to useInsertionEffect they'll avoid major performance issues.

The writing on the wall is more that we wouldn't encourage this mechanism over time because we find that <link> + inline styles have much better performance tradeoffs. Often, it's possible to implement a very similar API but statically extractable. That's great and we encourage that. But we wouldn't add a runtime helper like css() into React because we don't think this pattern scales well. Of course, we can't stop people from using it though.

I'm wondering how switching from a css-in-js library to <link> + inline styles would impact CLS. With css-in-js we have some built-in CLS protection in that I think it blocks the JS until the CSS is present, by definition. At the least, it sounds like <link> + inline styles would take more analysis effort to determine what the critical css is for any component.

CSS-in-JS and external <link> style sheets are not mutually exclusive.

There are a few toolkits out there that let you write component-oriented CSS-in-JS, but during build will extract everything to static external style sheets.

Thanks Dan - can you or anyone else point to something that details those performance tradeoffs in more detail? I think some of it has to do with css render-blocking when it's part of the JS.

"When to Insert <style> on The Client" in https://github.com/reactwg/react-18/discussions/110 describes some of the issues. Does this help?

Yes, thanks - after reading it more in depth. :) The "Future" section especially. I don't relish rewriting a legacy codebase that relies heavily upon css-in-js, hopefully the libraries will add compatibility.

Enzyme has been lagging in support for React features for several years now, so yes, I would expect it would not correctly support React 18 right away. (Note that both Enzyme and React Testing Library are independent of what test runner you're using - Jest, Mocha, etc).

> I would expect it would not correctly support React 18 right away

It's worse than you know, Enzyme will never support React 18, and it will likely never officially (or fully) support React 17. It's a completely dead project.

This right here. Enzyme’s dead, barring some major change, and people need to move off it.

https://dev.to/wojtekmaj/enzyme-is-dead-now-what-ekl

(Honestly I’m a bit surprised some big company hasn’t taken over Enzyme development - there most be teams facing hundreds ,or thousands, of hours on test rewriting)

Last I checked it still doesn't even fully support React 16

Not sure what Enzyme's plans are, since I know they depend on some React internals.

However, we've worked closely with the React Testing Library maintainers, and that's the solution I'd recommend for React tests going forward. We're fans of RTL because it encourages you to write tests "end-2-end"-like tests that resemble real-world scenarios and are resilient to implementation changes.

That's a shame, because there are plenty of use cases where testing a shallow render makes much more sense than fully rendering the component—for example, when you're wrapping a third-party library and simply need to test that the correct props are being passed, instead of testing the library's functionality.

Usually you can do this by mocking that specific library out at the module level. E.g. Jest has functionality for this.

Sure, but using Enzyme has been easier and far less brittle in my experience by being less reliant on hacky, library-specific mocking techniques. (Then again, I suppose you could argue that Enzyme is itself a giant hack, but it worked very well for me in the past.)

Reply on news.ycombinator.com