BLoC Pattern: Separating UI from Business Logic
The BLoC pattern treats app state as a stream: events go in, states come out. Use it in Flutter for complex state like user auth or data fetching. The footgun is overusing it for simple UI state, which creates unnecessary boilerplate.
Why it exists
In declarative UI frameworks like Flutter, widgets rebuild whenever their state changes. For complex apps, managing this state directly within UI widgets leads to tangled code where business logic and presentation are mixed. This makes the app difficult to test, reason about, and maintain as it grows.
The mental model
Think of a BLoC as a black box that sits between your UI and your business logic. The UI sends events (like 'LoginButtonPressed') into the box. The BLoC processes these events, performs any necessary work (like calling an API), and emits new states (like 'Loading', 'Success', or 'Error'). The UI simply listens to this stream of states and rebuilds itself accordingly.
How it works
A BLoC is a Dart class that manages a stream of states. The UI dispatches events to the BLoC to signify user actions or other triggers. The BLoC contains the business logic to handle these events, and upon processing, it outputs a new state. In Flutter, widgets like BlocBuilder and BlocListener subscribe to the BLoC's state stream and rebuild the UI only when a new state is emitted, ensuring a clean separation of concerns.
When to use it
BLoC is ideal for managing complex state that is shared across multiple screens or involves asynchronous operations. Use it for features like user authentication flows, shopping carts, or fetching and paginating data for an infinite list. Its strict separation makes business logic easy to test independently of the UI.
When not to use it
Avoid BLoC for simple, ephemeral state that is confined to a single widget. For example, managing the open/closed state of a dropdown menu or the text in a single form field is often better handled with a StatefulWidget and setState. The boilerplate of creating events, states, and the BLoC class is overkill for such trivial cases.
One canonical example
A login screen. The UI dispatches a LoginSubmitted event with an email and password. The AuthBloc receives this, emits an AuthLoading state, makes an API call, and then emits either an AuthSuccess state (triggering navigation to the home screen) or an AuthFailure state (displaying an error message). The UI code itself contains zero API logic; it only builds based on the current state from the BLoC.
Interview question
For which scenario would applying the BLoC pattern typically be considered an anti-pattern due to excessive boilerplate?
- a.Handling the state transitions during a multi-step user registration process involving API calls.
- b.Controlling the visibility of a simple dropdown menu within a single widget.Correct
- c.Managing the global theme settings and user preferences across an application.
- d.Orchestrating data fetching, caching, and pagination for a dynamic product catalog.
Why? this is the answer
The card explicitly states that BLoC is overkill for simple, ephemeral state confined to a single widget, like managing a dropdown's open/closed state. It is best suited for complex, shared, or asynchronous state, making the other options appropriate use cases.
Just read this? Test yourself on what you have been reading.
Read the original → bloclibrary.dev
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on flutter — each one lists the topics its interview covers.
See open roles