Setting screen options statically versus dynamically

WHAT THIS TESTS Whether you understand the lifecycle of screen options. Some options are known when you register the screen; others depend on state that only exists after the component renders. The interviewer wants the right tool for each.

A GOOD ANSWER COVERS The first way is the options prop on the Screen element. It can be a plain object or a function that receives route and navigation, so it can read route.params at registration time, for example setting the title from a passed userName. The second way is navigation.setOptions, called from inside the screen component, usually in useLayoutEffect with the relevant dependencies. This updates options on the fly. For a title that derives only from params, the options function is clean. For a title that follows component state, such as an editable document name held in useState, you must use setOptions because the static object cannot see later state.

COMMON WRONG ANSWERS Claiming the static options object can read component state, which it cannot, since it evaluates outside the component. Using useEffect instead of useLayoutEffect, causing a visible flash of the old title. Forgetting the dependency array on setOptions, leading to stale titles or update loops. Mutating the navigation options object directly.

LIKELY FOLLOW-UPS Why useLayoutEffect over useEffect for header updates? How do you put an interactive component, like a save button wired to local state, into the header? How do screenOptions on the navigator differ from per-screen options?

ONE CONCRETE EXAMPLE In an EditNote screen the title should mirror the text being typed. You keep title in useState, then call useLayoutEffect with a dependency on title that runs navigation.setOptions with headerTitle equal to title or a placeholder. As the user types, the header updates live. By contrast, a read-only Profile screen sets its title once via options: ({ route }) => ({ title: route.params.name }).