-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(deps): update to React 18 #526
Conversation
Or |
Should |
The last time I tried it, which was quite a while ago, the auto-formatting it applied actually broke things and needed manual cleanup by hand, and it was quite a significant amount of busywork. I just tried it again now and it looks like it applies some safe fixes fine, though there are many other linting warnings still present after. I think you can update the |
preloadState: preloadedState, | ||
history: history, | ||
it('removes a recording after receiving a notification', async () => { | ||
await act(async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some reasons behind wrapping these calls in act
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a lot of console warnings with the tests before adding that, but other than that not actually sure of the underlying reason why that fixes it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty odd! This only happens with *RecordingsTable
components :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like using iframe
for ReportView causes this issue. It uses onLoad
callback that updates React states outside React callstack, which throws a warning in tests. Surprisingly, this didn't get caught in old versions of React testing.
<iframe title="Automated Analysis" srcDoc={report} {...rest} onLoad={onLoad} hidden={!(loaded && isExpanded)} /> |
There are some rendering problems when actually running the web-client with React 18, it just seems a lot more clunky and slower to use. Currently investigating the reason. |
After a lot of digging and testing, I'm unable to pinpoint the root of the problems and there doesn't seem to be many problems from users online with React 18 in general with what is going on here - Thuan's PR does seems to speed up rendering but the main problem is that intermediate and default states seems to flicker in between rendering. The most obvious replication of this is if you click on the Recordings tab with an Active Recording and click to a different tab and keep clicking back and forth. There are hacks that can be used to solve these problems, but obviously this seems to be part of a bigger issue. So I'm beginning to wonder if it is a Patternfly issue or not since they do not fully support React 18 yet, and won't do so until their next release in early 2023. patternfly/patternfly-react#7142 (comment). If so, this should be put off until then, but for now it's unclear. Updating to React 18 isn't a priority in anyway either. |
This PR/issue depends on:
|
Not actually resolved, just autoclosed due to inactivity. |
Patternfly 5 has been released with full support of React 18 https://medium.com/patternfly/patternflys-major-release-everything-you-need-to-know-62f7c890ff57 Here's a full upgrade article: https://www.patternfly.org/get-started/upgrade/ |
Probably be better to start from scratch here. |
Fixes #482
Depends on patternfly/patternfly-react#7142
What's been updated:
What's been added:
Noteworthy: the update of
@testing-library/user-event
has made all their api calls to return promises, await and async should be used for those calls in our tests now. https://github.com/testing-library/user-event/releases/tag/v14.0.0