How would you manage network request state in a Flutter widget?

WHAT THIS TESTS: This question probes your understanding of state categorization in Flutter, specifically ephemeral versus app state, and whether you can cleanly separate side effects and data fetching from UI rendering. The interviewer wants to see that you recognize setState is sufficient for isolated widget logic but becomes unwieldy when state needs to be shared, tested, or survive widget rebuilds.

A GOOD ANSWER COVERS: First, define a sealed or abstract class representing the request lifecycle, such as RequestState with concrete states for Loading, Success with data, and Error with a message. Second, place the fetch call inside initState or an event handler rather than the build method, and update the state object via setState so the widget rebuilds to show a progress indicator, the loaded data, or an error banner. Third, explain the limitations of setState: the logic is trapped inside the widget, hard to unit test, easy to duplicate across screens, and prone to leaking if the widget disposes before the Future completes. Fourth, describe how a state management library like Provider, Riverpod, or Bloc moves that logic into a notifier, controller, or bloc, making the state observable from multiple widgets, enabling dependency injection for testing, and centralizing error handling and retry logic.

COMMON WRONG ANSWERS: A red flag is invoking the HTTP client directly inside the build method, which causes repeated requests on every rebuild. Another is using multiple boolean flags like isLoading and hasError instead of a single state class, which creates impossible combinations such as loading and error both being true. A third mistake is neglecting to handle widget disposal, leaving setState calls that throw exceptions after the widget is unmounted.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle pagination or pull-to-refresh with your chosen library, how to cancel an in-flight request when the user leaves the screen, or how to cache the response so the app works offline. They might also ask you to compare Riverpod against Bloc for a medium-sized team.

ONE CONCRETE EXAMPLE: Imagine a profile screen that fetches user data. With setState, the ProfilePage widget holds a User? user and bool isLoading, calls fetchUser in initState, and conditionally renders a CircularProgressIndicator or the profile card. With Riverpod, you create a FutureProvider or StateNotifier that exposes an AsyncValue, and the widget simply watches that provider and maps its when clauses to UI. If another screen needs the same user data, it can watch the same provider without duplicating the fetch logic.