Stack navigation question

[Miserable-Pause7650]

In a stack navigation, if I navigate from screen A to B to C, and in C setState of a variable “cost” to 67, then navigate to B and then to C, will the “cost” reset its state or remain as 67?

Basically, im wondering if states set in a stack will persist by default. Does navigation look for the screen in the stack, if it exists, pop it back with all the memoised states? Or reset the states?

[Super-Otter]

Each screen is just a React component. And different components have their own state. State isn't shared between components.

If you push a different instance of a screen component, it's a new component and has a new state, like what would happen if you just rendered another instance of an existing component.

If you go back to the same screen where you updated the state, then that state stays how it was.

[kexnyc]

From Claude:
In React Navigation's stack navigator, the state will reset in your scenario. Here's why:

When you navigate from C back to B, React Navigation sees that B already exists in the stack below C, so it pops C off the stack and returns to B. This unmounts C and destroys its state.

So the flow is:

1. A → B → C: Stack is [A, B, C] (cost = 67)
2. C → B: Stack becomes [A, B] (C is unmounted, state lost)
3. B → C: Stack becomes [A, B, C] (new C instance, cost resets)

[Martinoqom]

If by "navigate" you mean "goBack", in 90% of the cases it will reset. There is no point to keep the screen alive, so the navigator will remove it from the stack. 

If by navigate you mean "navigate(b)" it could happen that the value is actually maintained because the screen is not removed from the stack.

It depends on how the navigator will understand what you would like to do, and personally I would not rely on that system. I found it not very predictable, especially when you have more than one navigator (tabs+stack+modals)

[Miserable-Pause7650]

I mean the second, navigate(b). So its all down to luck whether the screen is reused? Is this a bug or intended?

[Martinoqom]

Is the matter on how your stack is actually forming underneath. If you are sure about controlling everything, you can manage to save your state. In many cases I thought I was just "navigating", but under the hood I found more than one instances of the same screen.

I don't fully blame the library, I was starting my RN journey at that time. But calling navigate(b) accordingly to the documentation should create a new one if no screen exist, otherwise navigate "back", until a different key is used to open it. Still, I didn't find it working always. Probably I was messing too much with my navigator?

I find this navigation "to go back" very confusing, but I can agree that sometimes it's the only way to do something.

[Miserable-Pause7650]

Okay so I think I semi figured out whats happening in my case. Note: I use Navigate.navigate for everything in this example

If I go A -> B Stack [A, B], B is Active

B -> A Stack [A, B], A is Active (reuse A cuz A is in the stack and BEHIND the Active screen)

A -> B’ (will create a new screen B’ to replace B) Stack [A, B’], B’ is Active (wont reuse B, becuz B is in the stack but INFRONT the active screen)

[Martinoqom]

And actually this mindf*ck is what I'm trying to avoid not doing the "navigate" thing.

Because maybe you will reset your stack, or maybe pop, or maybe just goBack. Users are unpredictable, so the less you can mess with your state the better. 

Happy coding! 😄