Solving Airline Frontend State Management with React Query and URL State, Without Global State Libraries

During the construction of the airline frontend, we considered adopting global state management libraries such as Zustand or Recoil, but ultimately decided against it. Initially, we were concerned about props drilling due to the large number of screens and deep component hierarchy, but in the actual implementation, we eliminated unnecessary global stores by clearly defining the ownership and lifecycle of state.

State Classification and Management Strategy

We redefined state along four axes and used tools appropriate for each.

• Server Data: Managed with React Query, controlling caching and refetching.
• URL State: Search conditions and filters are stored in the query string via the nuqs library.
• Shared Screen State: State unrelated to the server, such as UI steps or expansion status, is managed with Context.
• Local State: Toggles or values during input are handled with useState.

Avoiding props drilling and Performance Optimization

Server data is fetched directly by each component using React Query hooks. When the same key is used, only one server request occurs and the cache is utilized, making it efficient even without a global store. On the international flight booking detail screen, the useSuspenseBookingDetail hook is called in over 80 files, yet requests are not duplicated.

Loading and error handling are performed once at the root level, and child components (SuccessBody) are designed to operate assuming the existence of data. Since Context causes a full re-render of all children when its value changes, we included only values that do not change frequently and excluded items such as scroll position.

Benefits of URL State Management

Storing filter or sort state in the URL ensures state persistence upon refresh and enables link sharing. It also automates browser back-button support and serves as the sole channel for rendering the same screen in both webview and browser environments. As a result, there were almost no 'values with ambiguous ownership that need to persist for a long time' requiring a global store, allowing us to reliably manage complex screens without adopting such libraries.