-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Update React to v18 #11455
Update React to v18 #11455
Conversation
b938e04
to
539d98a
Compare
539d98a
to
76e8929
Compare
"@types/react": "18.0.15", | ||
"@types/react-dom": "18.0.6" |
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.
Can you clarify why a resolution on the repo is necessary?
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.
This is needed because of react-virtualized
, their latest release still uses React 16. Without the resolution block, type errors are shown e.g. 'List' cannot be used as a JSX component, similar to bvaughn/react-virtualized#1739
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.
I'm not a huge fan of resolutions since it does not solve the same problem for downstream extensions and applications. We should probably think of using react-window instead of react-virtualized
which is written by the same author and is a replacement for the latter (related). We can tackle it later if needed but we should probably mention something in the migration guide?
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.
I added a note in the migration guide.
8b56510
to
aa9fbf6
Compare
I rebased the changes on the latest master and fixed the conflicts. |
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.
I'd generally try to merge this relatively early in this month's dev cycle to find possible regressions and also address the outstanding comment from Vince (replacing the react-virtualized
package).
packages/plugin-ext/src/main/browser/comments/comment-thread-widget.tsx
Outdated
Show resolved
Hide resolved
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.
I'm fine with the changes as they are and I can't see any regressions in the application. After merging this, I'll take care of replacing react-virtualized
with react-window
.
@vince-fugnitto Any objections?
- remove usage of ReactDOM.render and use new root API - mitigate removal of the React render callback: remove onRender field from ReactDialog and ReactWidget. Subclasses are now adding the callbacks themselves. - list children prop explicitly - mitigate state batching in SearchInWorkspaceInput - fix return type in ToolbarImpl.renderGroupsInColumn Contributed on behalf of STMicroelectronics Signed-off-by: Alexandra Buzila <abuzila@eclipsesource.com>
Remove npm/npmjs/-/playwright-core/1.22.2 from dependency-check-baseline.json Contributed on behalf of STMicroelectronics Signed-off-by: Alexandra Buzila <abuzila@eclipsesource.com>
Update migration guide to mention react resolutions from package.json Contributed on behalf of STMicroelectronics Signed-off-by: Alexandra Buzila <abuzila@eclipsesource.com>
* make containerNodeRoot property readonly in CommentThreadWidget Contributed on behalf of STMicroelectronics Signed-off-by: Alexandra Buzila <abuzila@eclipsesource.com>
* update version Migration guide Contributed on behalf of STMicroelectronics Signed-off-by: Alexandra Buzila <abuzila@eclipsesource.com>
da1fcb5
to
7238267
Compare
I rebased the branch on the lastest master and fixed a conflict. |
@vince-fugnitto Any objections to merging this? I'll be merging this later today. |
@msujew I must have missed the ping from #11455 (review), I'm fine with merging and we can do the update we mentioned afterwards. |
What it does
This PR updates Theia to React v18. We adapted the invocations of React where necessary and made sure that Theia does not behave differently. With these changes in place we could not observe any regressions.
The major change in React v18 affecting the Theia codebase is the deprecation of the
ReactDOM.render
API. Although it is still available, we adapted all invocations of React to use the newcreateRoot
API, enabling new React v18 features like concurrent rendering throughout the code base. What we avoided is to explicitly use any of the new features to improve the Theia UX. This should be done separately.With the removal of the
render
API we lost the option to use its render callbacks to trigger functionality in Theia. In consequence, theonRender
field fromReactDialog
andReactWidget
was removed. Users of the render callbacks are adapted to use the equivalentref
callbacks oruseEffect
patterns instead.Other minor updates:
children
prop now needs to be explicitly specified when neededSearchInWorkspaceInput
was using an intermediate state, this is fixed now)Consumer code will most likely continue to work, especially when using
ReactDOM.render
for now instead of the new API, as the new features of React are then not used. In extreme cases, React 17 could be additionally loaded and used for their own code.If a jump directly to v18 is not desired at the moment, we also prepared a branch which updates React to v17: https://github.com/eclipsesource/theia/tree/react-v17-update
Review checklist
Reminder for reviewers
Contributed on behalf of STMicroelectronics
Signed-off-by: Alexandra Buzila abuzila@eclipsesource.com