You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Code example came from this discussion: facebook/react-native#2442. As is discussed there, however, this is probably brittle and not recommended.
If we don't take this approach, we probably need to be able to pass components to the native module controlling the navigation controller and then push those component onto the navigation stack. This will enable the navigation to be controlled from RN or Obj-C.
The benefit of this would be that we could push native Obj-C and RN views onto the same navigation stack without having to have it all implemented on one side.
The more I think about it though, I'm not sure this is the best thing to encourage. It might be better to simply encourage keeping navigation native in Obj-C at first, and just use RN views where they are needed. Then, when one full branch of navigation has RN implemented for each screen, move the navigation into RN. If there is a view that is very hard to port to RN, it could easily be wrapped as a native view module and called from RN.
The text was updated successfully, but these errors were encountered:
One way may be to hook into NavigatorIOS's backing viewController like this:
Code example came from this discussion: facebook/react-native#2442. As is discussed there, however, this is probably brittle and not recommended.
If we don't take this approach, we probably need to be able to pass components to the native module controlling the navigation controller and then push those component onto the navigation stack. This will enable the navigation to be controlled from RN or Obj-C.
The benefit of this would be that we could push native Obj-C and RN views onto the same navigation stack without having to have it all implemented on one side.
The more I think about it though, I'm not sure this is the best thing to encourage. It might be better to simply encourage keeping navigation native in Obj-C at first, and just use RN views where they are needed. Then, when one full branch of navigation has RN implemented for each screen, move the navigation into RN. If there is a view that is very hard to port to RN, it could easily be wrapped as a native view module and called from RN.
The text was updated successfully, but these errors were encountered: