navigate vs push in a Stack Navigator

WHAT THIS TESTS This checks understanding of stack navigation semantics, specifically the difference between idempotent navigation and explicitly stacking duplicate screens.

A GOOD ANSWER COVERS In a Stack Navigator, navigate is context-aware. If the target route is not already in the current stack, it pushes a new screen. But if an instance of that route already exists, navigate will not add a duplicate; it navigates back to the existing instance, and if you pass new params it can update that existing screen rather than stacking another. push is unconditional: it always puts a new instance of the route on top of the stack, regardless of whether the same route already appears below. This means calling push repeatedly for the same route name builds a deepening stack of that screen, each with its own params, while repeated navigate to a route already on top generally does not grow the stack. The practical rule is to use push when you specifically want to navigate to another copy of the same screen type with different data, and navigate for normal goto-a-screen intent.

COMMON WRONG ANSWERS Claiming navigate always creates a brand new screen, ignoring that it reuses existing instances. Thinking push and navigate are identical. Believing navigate pops the stack, which it does not by itself.

LIKELY FOLLOW-UPS How do params update when navigate hits an existing route? What does the back button do after several pushes? When would you use replace instead?

ONE CONCRETE EXAMPLE A social app where each Profile screen links to another user's Profile. Using push when tapping a friend keeps stacking Profile screens, so the user can press back through the chain of profiles they viewed. If you used navigate, returning to an already-present Profile route could collapse back to it instead of stacking, which is wrong for this drill-down pattern.