4 ms·

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 en

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.

acemarke 5y ago
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).
- rkuykendall-com 5y ago
  > 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.
  - vosper 5y ago
    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 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)
  - rimunroe 5y ago
    Last I checked it still doesn't even fully support React 16
tshaddox 5y ago
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 https://github.com/reactwg/react-18/discussions/110
- danabramov 5y ago
  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.
  - tunesmith 5y ago
    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.
    - danabramov 5y ago
      "When to Insert <style> on The Client" in https://github.com/reactwg/react-18/discussions/110 https://github.com/reactwg/react-18/discussions/110 describes some of the issues. Does this help?
      - tunesmith 5y ago
        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.
  - tunesmith 5y ago
    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.
acdlite 5y ago
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.
- RussianCow 5y ago
  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.
  - danabramov 5y ago
    Usually you can do this by mocking that specific library out at the module level. E.g. Jest has functionality for this.
    - RussianCow 5y ago
      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.)

acemarke 5y ago

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).

rkuykendall-com 5y ago
> 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.
- vosper 5y ago
  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 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)
- rimunroe 5y ago
  Last I checked it still doesn't even fully support React 16

tshaddox 5y ago

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 https://github.com/reactwg/react-18/discussions/110

danabramov 5y ago
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.
- tunesmith 5y ago
  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.
  - danabramov 5y ago
    "When to Insert <style> on The Client" in https://github.com/reactwg/react-18/discussions/110 https://github.com/reactwg/react-18/discussions/110 describes some of the issues. Does this help?
    - tunesmith 5y ago
      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.
- tunesmith 5y ago
  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.

acdlite 5y ago

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.

RussianCow 5y ago
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.
- danabramov 5y ago
  Usually you can do this by mocking that specific library out at the module level. E.g. Jest has functionality for this.
  - RussianCow 5y ago
    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.)