-
-
Notifications
You must be signed in to change notification settings - Fork 39
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
Context doesn't behave as expected #34
Comments
Same issue for me. Took me a while to figure out what was wrong - i have a nested context provider overriding the parent one, but everything inside was using the wrong context values despite it being inside the nested provider. |
From my understanding, that's currently not feasible in React Native. |
After a lot of digging, I found out that At first glance, I found this preposterous. But after some reflection, I think it makes sense. The opposite is true for RN. Modals are first class, Portals are a hack. So I practically rewrote a couple of libraries I used that depend on I think this library can be misleading and is applied in situations where @gorhom - you're the author of both |
portals have no "cost", they are a virtual thing. Modal is a tangible component that adds another layer to your UI and can cause some inconsistent/unexpected behaviour as it is dependant on both React Native's implementation and platform's own implementation which can change between OS versions |
Portals aren't a DOM thing, they're a hierarchy thing. The purpose of a portal is to enable declarative rendering from within a given component to a target that is higher up in the tree. If you just use |
@mrjackdavis Modal, on Android, forces the navigation bars to become visible. So just like @lightrow says, it can have some unexpected behavior. My app is always full-screen so I've actually had to replace Modal with |
Perhaps rather than discuss the semantics and side effects of portals vs modals here, I'm just going to reitterate the issue root problem:
As for alternatives: If this issue impacts you, an alternative is to use Unless the behavior of this library is adjusted, which is probably a breaking change, that's what we're stuck with. I won't close this issue in case that is still a possibility Pick your poison I guess... (Edited for clarity) |
Yep. I wonder if it's possible to write a native module that behaves like |
Hey!
I come from
ReactDOM
land whereReactDOM.createPortal
exists and I see this library as the react-native alternative.One key behaviour of
ReactDOM.createPortal
that I've come to expect, is that a rendered component that is portaled, maintains the context of where the element was defined.See this issue for an example enesozturk/react-native-hold-menu#82 (comment)
I can also see confusion about this behaviour in #2, #3 and #31. The workaround seems to be to either re-order context providers. I have some cases where that is not feasible.
I dove into the source and understand why the behaviour is as it is.
@gorhom, have you thought about this previously? Is there a way to arrive at this behaviour without some sort of first-class implementation by react or react-native?
The text was updated successfully, but these errors were encountered: