@benny I'm using react navigation 5.
Here's my setup: https://gist.github.com/olivergeorge/981bc5135fa47253cba50fd125495d0b
The interop.navigation/*navigator
keeps the navigator ref which allows me to do navigation from re-frame fx (not relying on component props).
I think this solution hits a snag when you have nested navigators, and you want the action to be dispatched against a child navigator - usually the parent of the screen where you're dispatching the event to effect the navigation. What I ended up doing recently was using the navigator ref as you're doing here to persist nav state for reloads, but wrapping the event dispatch function to add the navigation prop (from useNavigation
) to the event as metadata. Then the effect handler uses that to dispatch the navigation action, rather than the root navigator in the ref.
looks like some earlier messages in this thread were archived already, so apologies if my response is missing some important context 🙂
Hi Anson. I found nested navigators fiddly but doable.
; event handler
(rf/reg-event-fx :home-my-map-press
[]
{:dispatch [:setup-route :app.screens/my-map]
:navigate2 ["TabStack" {:screen "MapStack"}]})
; fx
(rf/reg-fx :navigate2 (fn [[a b]] (navigation/navigate2 a b)))
; helper
(defn navigate2 [a b] (.navigate @*navigator a (clj->js b)))
As for testing... perhaps others will have good suggestions. Worth teasing out what you want to test then talking about those specific cases.
Note the interop.navigation/*initial-state
trick... that reloads navigation state so that Figwheel style hot reloading doesn't reset the navigation state.
this is great, thanks @olivergeorge!
I ended up doing just that, teased out the re-frame-related code and shadow just compiles what i use so i just pulled out any native-related stuff