Integrating autologging surface tree to React native #264
Conversation
meta-cla
bot
added
the
CLA Signed
srinathvijay
force-pushed
the
react-native-surface-tree
branch
from
5c168f6 to
ed24ded
Compare
| children | ||
| ); | ||
| } | ||
| // DOM-specific wrapper creation - commented out for React Native compatibility |
There was a problem hiding this comment.
With these types of things commented out, does the functionality you were testing in RN still work?
It seems like a lot of changes are specific to element reference, nodeRef is optional so it should be fine to just not pass for RN case.
The element specific things I'm wondering how we should approach conditionally doing vs. not doing those things depending on run context.
cc: @reshadi for thoughts
There was a problem hiding this comment.
Yes, looks like all the changes is just about the element, we can make that optional, also in typescript we can use "interface merging" to define an HTMLElement type that can help us continue compiling code in RN even if those types are not defined.
I'm also thinking about splitting these components further to to server the the web/RN versions that have different useLayoutEffect.
| } | ||
|
|
||
| SurfaceProxy.init({ ...options, surfaceComponent: Surface }); | ||
| // SurfaceProxy.init({ ...options, surfaceComponent: Surface }); |
There was a problem hiding this comment.
We confirmed there is no createPortal in RN right? This would be something else specific to web we need to conditionally do.
| } | ||
| // DOM-specific lookup - commented out for React Native compatibility | ||
| // React Native doesn't have document.querySelectorAll | ||
| // const el = document.querySelectorAll(`[${this.domAttributeName}="${this.domAttributeValue}"]`); |
There was a problem hiding this comment.
This seems like just a fallback, I wonder if it is needed if we fully trust ALSurfaceData to be the SoT
ALSurfaceUtils.tsfile, that extracts all platform agnostic logic and can be shared with web and react native