-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Strict mode compat (web) by removing findNodeHandle #4802
Comments
Hey! 👋 The issue doesn't seem to contain a minimal reproduction. Could you provide a snack or a link to a GitHub repository under your username that reproduces the problem? |
Hey @natew, thanks for pointing out this. Someone from our team will take a look at it soon. |
It does, thank you a bunch, will look forward to the release with it. I'm not positive but my guess is our drop in performance/lighthouse recently on the site was due to this causing React to de-opt concurrent rendering which makes our main thread work go up quite a bit. Testing that next.. |
@m-bert Seems Edit: After running the NextExample from the reanimated main branch, and adding |
Hi @asenmitrev! It is possible that something has changed and now |
Hi @asenmitrev! Could you please check if this PR works and warnings are gone? |
@m-bert checked on NextExample in the PR branch and seems the warning is gone. All seems good, thank you! |
## Summary See [this issue](#4802) for context. It seems that `findNodeHandle` was still used on web in `JSPropUpdater`. This PR removes its usage. ## Known issue It seems that in `findNodeHandle(ref) === ref` (used in `createAnimatedComponent` ) isn't true in all cases (it can happen for example with `SVG`) ## Test plan Tested on update props performance example inside `<React.StrictMode>`
## Summary See [this issue](#4802) for context. It seems that `findNodeHandle` was still used on web in `JSPropUpdater`. This PR removes its usage. ## Known issue It seems that in `findNodeHandle(ref) === ref` (used in `createAnimatedComponent` ) isn't true in all cases (it can happen for example with `SVG`) ## Test plan Tested on update props performance example inside `<React.StrictMode>`
Still seem to be getting this on 3.5.4 |
@apetta Yes, because this PR was not released yet (will be released in 3.6.0). For now, you can use |
@apetta FYI we have just published react-native-reanimated@3.6.0. |
hi, @tomekzaw, this issue still exists on iOS with react-native-reanimated 3.6.1
|
Hi @m-bert , thank you for your reply, I'm not familiar with the source code of react-native-reanimated, so I don't know if I'm right, but I took a quick look at #5654, and it looks like it's just for the web. Take for example the following statement: Does this mean findNodeHandle is still being called for platforms other than the web? |
Exactly, this PR removes those call from web. This was the original problem in the issue. |
Hi @m-bert , I found a merged pr Deprecate findDOMNode in StrictMode, according to the reply, it looks like all usages should be deprecated, maybe this issue should be applied to all platforms, not only web? |
@YaoHuiJi Would be great to do that but |
## Summary As mentioned in [this comment](#4802 (comment)), some of `findNodeHandle` calls are still present on web. This PR aims to remove them in order to get rid of errors in `StrictMode`. ## Test plan Tested on examples (mainly with scroll, like "ScrollViewExample" or "ScrollEventExample")
Description
On web you get errors:
This is due to
findNodeHandle
which according to react-native-web is deprecated:https://github.com/necolas/react-native-web/blob/ef95fc0c2b40cc0d3743df4b56485a16a8442e5f/packages/react-native-web/src/exports/findNodeHandle/index.js#L17
Would be nice to remove this usage. I can help with this with just some light pointers in terms of what thats needed for now.
Steps to reproduce
Use any animated component on web, sorry for no repro but easy to trigger.
Snack or a link to a repository
https://snack.expo.io/
Reanimated version
3.3.0
React Native version
0.72.0
Platforms
Web
JavaScript runtime
None
Workflow
None
Architecture
None
Build type
None
Device
None
Device model
No response
Acknowledgements
Yes
The text was updated successfully, but these errors were encountered: