Adding reset to router

[wcastand]

I need to reset my route quite often and being forced into using the navigation to reset means i don't have expo-router logic and need to do it by hand (tabs, sub stack, etc)

having a router.reset() would be amazing.

doc suggest to use replace but it's not the same thing, replace doesn't clear the history.

[likeSo]

I want this too. In the official example, The useAuth() hook uses router.replace('/') to navigate to the homepage after logged-in. But I can still slide back to the login screen! This is not practical!!

[mateitudose]

Exactly this!

[mateitudose]

Actually, users can still slide back but nothing will happen because of the useProtectedRoute hook. But having to go back like 3-4 times to clean the router stack and then exit the app is annoying and bad UX

[NandoMB]

What I'm doing as workaround to bypass this:

function clearHistory() {
    const state = navigation.getState();
    navigation.reset({
      ...state,
      routes: state.routes.map(route => ({ ...route, state: undefined }))
    });
  }

It'll have the similar effect as router.replace('/actual-href'). So, if I call the replace method, the app will literally reload, using clearHistory not....

[rick-yao]

how did you use clearhistory function ? i use it like below , but did not work for me. neither did router.replace()

[NandoMB]

The clearHistory could no be after router.push, because your component will be unmounted... Have you tried to change the order?

Actually I'm using it in different way:

const onSelectItemHandler = useCallback((profile: Profile) => {
    onChangeActiveProfile(profile);
    ref.current?.close(); // Here it's a ActionSheet component being closed...
    clearHistory();
  }, []);

So, I close the actionsheet and then clear the history. I didn't used it with router.push() but I think it should work...

[leggomuhgreggo]

Should be doable with the useNavigation`, no?

Would urge caution against mutating history too much though. Very easy for this to clash with other behaviors and it violates user expectations. There are valid reasons to use reset but often as not this reflects an underlying dynamic that could be addressed through less convoluted means, like redirects or shared routes or conditional rendering.

[wcastand]

it's doable but not safe as you said, would be better to have something handled by expo-router to have proper state.

[erquhart]

This is table stakes for even a simple app.

[rick-yao]

so is there a way to prevent user slide back to login page ?
i have read https://reactnavigation.org/docs/navigation-prop/#reset but when i use useNavigation of expo/router, i got this
does expo/router prevent me from using reset() ? also is there really a way to clear the stack history?

[NandoMB]

Have you tried this?

[likeSo]

Disable gesture actually is not a good idea. For me, the gesture still available even i disabled it...... But for now it's the only way

[Raduc4]

@rick-yao have you found the solution for this?
Somehow, the routes: [{name: ""}] doesn't match with RootParamList
Do you use a <Slot />?

[rick-yao]

@Raduc4 not fully solved , my goal is to prevent user from going back to main page (which is login page). All my actual code is in (tabs) folder , so i use router.replace whenever in login flow. So...it is temporarily solved.

[Raduc4]

@rick-yao I also could go back from (tabs) to (auth). The problem was because of the layout I used.

home/
├── event
            |------[event].tsx 
├── index.tsx
├── _layout.tsx
└── messages.tsx

Whenever I was going to [event] the go-back process ended up in (auth)/start which is my first page.
This seems like a bug, will be needed an issue to be opened

[tslater]

Just to clarify (or propose) a valid and common use cases:
Login => If I have navigation before login, I want to forget that and not let users go back UNLESS they logout. This is the one discussed here.
Logout => I don't want users that log out to retain either their history before logging in, nor after. This is a fair nuke.

[wcastand]

any chance we get a comment from the expo team is they plan to add this or if we need to do custom stuff forever? because expo 49 upgrade broke the onboarding of my app where i was doing a custom reset using the rootNav.reset :/

[joeyscarim]

is there any current way, hacky or not, that i can reset the navigators? I have tabs, each with their own stack of pages, and I need to reset everything when a user switches "teams", changing the content and access that each tab and stack page shows

[tchojnacki]

I've had some success using:

while (router.canGoBack()) { // Pop from stack until one element is left
  router.back();
}
router.replace(newPath); // Replace the last remaining stack element

It isn't perfect, but seems to work most reliably out of options provided in this thread, at least for my use case.

[n-ii-ma]

While this works great, It would be better to get an official solution from Expo Router.

[elmaxe]

This has the same effect as the above solution:

import { StackActions } from '@react-navigation/native';
import { router, useNavigationContainerRef } from 'expo-router';


const rootNavigation = useNavigationContainerRef();

const navigate = () => {
	rootNavigation.dispatch(StackActions.popToTop());
	router.replace(newPath);
}

useNavigation also works instead of useNavigationContainerRef/useRootNavigation

[oldo]

Thanks @elmaxe after trying a bunch of proposed solutions, this worked fro me

[gauravvermatechno]

Thanks @elmaxe . ur solution did really work

[JRS-Developer]

@elmaxe Works good but it causes a back animation that I didn't want to have, my solution to this is using reset:

const rootNavigation = useNavigationContainerRef();
navigationContainer.reset({
          routes: [{ name: "(tabs)" }],
});

In this case name is "(tabs)" because I have my index page inside folder "(tabs)".

[wcastand]

the way i clear the nav history is like this.

import { CommonActions } from "@react-navigation/native"

[...]

const nav = useRootNavigation()

[...]

nav?.dispatch((state) =>
  CommonActions.reset({
    ...state,
    routes: [{ name: "/your-route" }],
    index: 0
  }),
)```

[seanislegend]

@dannybit Are you using valid route names when doing so? I had the issue when I was using folder names instead. You can find the proper names with navigation.getState(), it will list all available routeNames.

[nwazuo]

@seanislegend When I call navigation.getState(), the routeNames listed are those which belong to the immediate parent route. It seems that you can only reset within the nearest route stack.

[wcastand]

are you sure you are using the useRootNavigation and not the useRouter ? i get all the route as far as i know

[nwazuo]

@wcastand You're right. I now use useRootNavigation and am able to reset the state accurately but it's a bit more verbose than I'd like but works fine.

[thozh]

Is there a way to add type safety with the name of routes used in the CommonActions ?

[wcastand]

can we get anyone from the expo team to actually answer? or give something, anything?

we have legit use cases for this for many people and still no one seem to care :/

It's a bit frustrating at times to never get help/answers, here or on discord :/

Sorry a bit frustrated that ticket is almost a year old soon and no one ever bothered to give insight if that's something that will be done or will never happen.

If you decided to not listen to community that's fine but then let us know so we know where we stand and that it's a close project(close ideas in discussions then) and we know we need to make support expo ticket for paid users to get answers :)

[pmakowski23]

Would love to also see what they suggest to do!

[Mik1337]

i was facing a similar issue, i solved it by re-structuring my projects app folder like this

The issue i was facing was that i couldn't reset the navigation after i completed my onboarding screens, but if i disabled gestures in the main layout, the customer won't be able to navigate back, which pretty much does the same job as a navigation reset would do in this situation.

here's my old project structure

app
├── (app)
├── index.js <- main entry for app
├── _layout.js <- main layout file
├── onboarding
└── seeall

So, i created a new route grouping called (stack), and disabled gestureNavigation in the main layout and enabled it only inside my (stack)

app
├── (stack)
│   ├── _layout.js <- layout for rest of app, gestureNavigation: true
|── _layout.js <- main layout, gestureNavigation: false
├── index.js  <- main entry for app 
└── onboarding

this seems to work as i expect, after my onboarding is done i router.replace to my home screen which lives inside my (stack) and from here i can't swipe back to my index or onboarding pages

This is ofc not a universal substiture for navigation.reset, but works in this situation...

[wcastand]

did you disabled the back button too for android? otherwise android user can still go back using the physical back button in theory no?

[Mik1337]

yeah, you're right. I didn't think about this until later; i had to write some extra code for it...

I had to add this in my (stack)/_layout.js to disable gesture based navigation

  const navigation = useNavigation();

  Platform.OS === "android" &&
    React.useEffect(() => {
      navigation.addListener("disable_back_gesture", (e) => {
        if (e.data.action.type === "GO_BACK") {
          e.preventDefault();
          console.log("Prevented back gesture");
        }
      });
    }, []);

and this in my home page, the page that's rendered immediately after my onboarding screens in my app, to disable the backbutton

  // I'm importing useFocusEffect from @react-navigation/native
  Platform.OS === "android" &&
    useFocusEffect(() => {
      // disable back button only on home screen
      const backButtonHandler = BackHandler.addEventListener(
        "disable_back_button",
        () => true
      );
      return () => backButtonHandler.remove();
    });

This seems to work for now, but it feels very hacky lol. I probably need to write some navigation tests to confirm it's behavior 🥲

[mewuto]

@wcastand
I was just looking at the documentation and saw something like this.
I had a similar problem, but I solved it!!
ref: https://docs.expo.dev/router/migrate/from-react-navigation/#reset-navigation-state

import { useNavigation } from 'expo-router'
import { CommonActions } from '@react-navigation/native'

export default function Screen() {
  const navigation = useNavigation();

  const handleResetAction = () => {
    navigation.dispatch(CommonActions.reset({
      routes: [{key: "(tabs)", name: "(tabs)"}]
    }))
  }

  return (
    <>
      {/* ...rest of the code */}
      <Button title='Reset' onPress={handleResetAction} />
    </>
  );
}

[bryanprimus]

how do you reset to base path / ? i tried index but it doesn't work

edit: index is working as expected

[thozh]

this worked for me

[abdrhxyii]

Hey @mewuto , Thank you bro..... it worked for me !

[Seamus1989]

why is this hard, the above example does something but not what most use cases would desire. Thanks for the post but Expo that hardly helps

[abdrhxyii]

https://docs.expo.dev/router/migrate/from-react-navigation/#reset-navigation-state

Check this out

[oldo]

This worked for me: #495 (reply in thread)

[oldo]

No sorry, I haven't come across that error

[ToshiyukiTakahashi0915]

I encountered the same error, and I believe it's likely due to the stacks not being properly nested. We need to differentiate the processing based on whether there is more than one stack nested or not.

[qaezrun]

Hello @thozh and @ToshiyukiTakahashi0915 how you solved that issue? I've tried @ToshiyukiTakahashi0915 solution. I checked if routes of getState and getRootState if its length > 1 ill call the popToTop but it turns out my route.length is always 1.

[AurelienV-42]

Hey!
First check if you can popToTop with router.canDismiss() (and btw, router.dismissAll seems to be like popToTop?)

Here's my hook:

const useResetRoute = () => {
  const router = useRouter();

  const resetTo = (route: string) => {
    if (router.canDismiss()) router.dismissAll();
    router.replace(route);
  };

  return resetTo;
};

[m-shazaib]

I was having this error before
The action 'POP_TO_TOP' was not handled by any navigator.

Is there any screen to go back to?

This is a development-only warning and won't be shown in production.
I was getting this issue on this code block.

 router.replace("/auth/signin");

But @AurelienV-42 your solution worked for me.

[wcastand]

moved the discussion to the expo repo
expo/expo#28485

[gabrielsh2]

In my case, I needed to resolve that same cenario that some people was struggling as well.

Just to clarify (or propose) a valid and common use cases: Login => If I have navigation before login, I want to forget that and not let users go back UNLESS they logout. This is the one discussed here. Logout => I don't want users that log out to retain either their history before logging in, nor after. This is a fair nuke.

I will share my solution in case it helps someone with de same issue.

I changed the way that I was structuring my routes and _layouts, before it was something like this

app
├── (app)
│         ├── _layout.js <- used my session context to make routes nested here private, Using Slot.
│         └──  index.js <- my home screen that need auth
 |── _layout.js <- using Stack here
├── sigIn.js 
└── signUp

The problem with that approach was that Stack on the root layout, because when I navigate from the auth pages to the home, I needed to reset the Stack state, the same issue for a logout flow redirecting from home to signIn.

Now, I'm using this approach:

app
├── (app)
│         ├── _layout.js <- used my session context to make routes nested here private, Using Stack.
│         └── index.js <- my home screen that need auth
├── (auth)
│         ├── _layout.js <- Using Stack.
│         ├──  sigIn.js
│         └──  sigUp.js
└── _layout.js <- using Slot 

Using a Slot and creating different Stacks for different flows solved my problem. When I call router.navigate from signIn to the home I'm changing the Stack instance that is rendered, then I don't have to reset.

[Mik1337]

i think this is identical to the approach i took, but are you handling back button / gestures that's found in android devices ?

i had to do this to account for that
#495 (reply in thread)

[gabrielsh2]

Unfortunately, I didn't notice that behavior. For now, I'll follow the same approach you did

[naytun]

My solution is similar to @Mik1337, using useFocusEffect(). Since we cannot use router.replace() with useEffect() due to the component not finished mounting, we have to replace the route after component did finish mounting.

   //=== Check Auth
   useFocusEffect(() => {
      if (!!authState && !!!authState?.authenticated) {
         router.replace('/')
      }
   })

[doles22]

Im using firebase auth so this code snip wont work for everyone, but conceptually I solved this by making sure on every screen I check the users authentication status at the start of every screen.

const user: FirebaseAuthTypes.User | null = auth().currentUser;

    // Check if user is authenticated, redirect if not
    useFocusEffect(
      useCallback(() => {
        if (!user) { 
          router.replace('/YOUR_SIGN_IN_SCREEN');
        }
      }, [user])
    );

Im also using expo router to navigate and on the sign in screen I just navigate with a router.replace() option to my landing screen so it removes the option for the user to go back to the sign in screen.

These two things seems to create a decent experience that way if a user does try and use back after a sign out it just routes them right back to my sign in screen.

It's working well so far and gets around the issue of a poor navigation experience for my users.

Would be awesome to see expo router have a clear history option though to start the navigation history over after a sign in or a sign out. Seems like a great opportunity to encourage more router usage vs have to get this type of feature with react native navigation.

[Re1nGer]

I've found this solution helpful: expo/expo#28485

      router.dismissAll();
      router.replace('/sign-in')

[lewisdonovan]

Worked like a charm!

[gabriel-logan]

I've found this solution helpful: expo/expo#28485

      router.dismissAll();
      router.replace('/sign-in')

This works, but the Expo team needs to stop being so damn indifferent to the users of this framework. No one responds to something as important as this; it's basically an invitation to ditch Expo and switch to React Native CLI for good, never looking back. I've seen millions of similar cases.

But again, THIS WORKS. I just don't know what new problems this might cause.

[vilnytskyi]

Just note that @Re1nGer's solution will fail in case history contains only one route, so router.canGoBack() returns false.
I've ended up with creating custom router wrapper and using it instead router from expo-router:

import { router as expoRouter } from 'expo-router'
import type { ExpoRouter } from 'expo-router/types/expo-router'
import type { RouteName } from './routeNames'

interface Router extends ExpoRouter.Router {
  reset(route: RouteName): void
}

export const router: Router = {
  ...expoRouter,
  reset(route: RouteName) {
    if (router.canGoBack()) router.dismissAll()
    router.replace(route)
  },
}

// Usage example
import { router } from '@router'
router.reset(RouteName.Home)

[sweelemk]

Hi there,
I have following structure

export default function Layout() {
  return (
    <Stack
      screenOptions={{
        headerShown: false,
        gestureEnabled: false,
      }}>
      <Stack.Screen name="index" />
      <Stack.Screen name="page-1" />
      <Stack.Screen name="page-2" />
      <Stack.Screen name="page-3" />
    </Stack>
  );
}

I have requirements to implement behaviour: I'm on index page, when click on button I redirect to page-3. But when I click on back button (I use custom back button, and use router.back()) I would like to get to page-2 -> page-1 -> index.

Is this possible or not?

Thank you

[wcastand]

you can replace you custom back button in each screen with the proper path you want the back button to redirect.

<Stack.Screen option={{headerLeft: () => { your custom back with proper route }}} />

[quememo]

any reason to use router.dismissAll() instead of navigation.reset ?

[wcastand]

Reset doesn't match the expo router logic so the state you get after reset break expo router
Also it doesn't have expo router logic for the routes so can't use the same route syntax somehow when i tried.

[quememo]

In what way does it break it? I tried it and seems fine for my use case, but i would like to know more in case I come across any details

[wcastand]

just the state wasn't usable for expo-router and was missing values. reset doesn't provide a default route for exemple, which you need most of the time in expo-router, if you want to reset to a specific route, but that route is inside group and folders with params etc, the state is quite complicated to get right since you have to do it by hand with reset.

[quememo]

So, is dismissAll preferred in all scenarios, or does it have any drawbacks?

[wcastand]

in my case i see one small drawback but specific to my setup, dismissAll won't re-trigger the query in the screen, so sometime we don't get updated data, can use useFocusEffect to force it. or in our case it's mainly happening because we are in the middle of switching between RESt to graphql so it should not be an issue later on.

[GuilhermeSilva00]

I can't use router.replace('/'), this don't work. It's so importat has reset method in expo-router. I needed to use router.navigate(/) and disable hardwareBackPress in my first screen, it's so bad.

[sajjadjaved01]

Worked for me:

  router.dismissAll();
router.replace("/screens/dashboard");

[Ha1fByte]

Both of the code chunks that people provided worked for me in the end, but the router.dismissAll() worked better because it didn't interfere with testing like the useNavigation() one did.

router.dismissAll();
router.replace(Routes.MainScreen);

const navigator = useNavigation();

...

  navigator.dispatch(
    CommonActions.reset({
      index  : 0,
      routes : [
        { name: Routes.MainScreen},
      ],
    })
  );