iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Use context.value<B, S>() when the widget’s build needs the current state as a plain value and should respond to state emissions. Use context.state<B, S>() when you need the underlying ReadonlySignal<S> for reactive composition and do not want that lookup to register the calling widget element for rebuilds.
These are BlocSignal extensions on Flutter’s BuildContext, provided by bloc_signals_flutter; they are not built-in Flutter methods. The distinction is useful because it makes the consumer’s intent visible in the API: read a value for a widget build, or pass a signal into another reactive construct.
What do the two methods return?
The methods are not interchangeable: one unwraps the current state, while the other exposes the state signal.
| Method | Return type | What the lookup means for the calling widget | Typical use |
|---|---|---|---|
context.value<B, S>() |
S, the current raw state value |
The widget element is registered to rebuild when the state emits. | Read state directly while building UI that should update with it. |
context.state<B, S>() |
ReadonlySignal<S> |
The lookup itself does not register an element rebuild dependency for each state emission. | Pass the signal to a reactive computation or effect. |
The official bloc_signals_flutter changelog describes context.state as a way to access the underlying read-only signal without registering an element rebuild dependency, for composition with computed() or effect().
#1 Best Overall
When should I use context.value?
Use it when the widget’s own build output depends on the current state and should be updated as the state changes. The call gives you an S, so the build code can use the value directly:
final count = context.value<CounterCubit, int>();
return Text('Count: $count');In this example, the widget element that makes the lookup has a state-emission dependency. Choose this form when that is the intended relationship between the state and the widget’s rendered output.
When should I use context.state?
Use it when you need the signal itself so another reactive construct can consume it. For example, a computed value can derive whether a counter is even:
final counterSignal = context.state<CounterCubit, int>();
final isEven = computed(() => counterSignal.value.isEven);Here, context.state retrieves the signal; it does not make the calling widget element rebuild on every emission. The downstream reactive consumer is responsible for reacting to signal changes. The package API documentation shows this pattern alongside the raw-value pattern.
Why have both names?
The pair distinguishes two jobs that can otherwise be easy to blur: obtaining state as a value for a widget build, and obtaining the signal as an input to further reactive work. That distinction gives a reader of the code a clue about where updates are expected to be handled.
The naming also fits a broader pairing in BlocSignal’s APIs. The bloc_signals changelog records that version 1.4.0 added container.value as an alias for container.stateValue, aligning the container’s value and signal naming with container.state and the context extensions. The changelog for bloc_signals_flutter records the context extensions as additions in version 1.3.0.
Rank #4
How should I choose?
- Choose
context.valuewhen the current widget build should read a plain state value and respond to its emissions. - Choose
context.statewhen signal composition, such as acomputed()oreffect(), should consume the signal.
The distinction is about the calling element’s dependency and the return type, not a blanket claim that one approach is faster. The cited package documentation establishes the API behavior and examples; it does not report benchmark results comparing rebuild counts, performance, or productivity across architectures.
What about limiting rebuild scope?
The article by Randal L. Schwartz also presents using Flutter’s Builder to scope a value lookup to a smaller widget element, and composing signals from multiple containers. Those are architectural techniques rather than guarantees that any particular overall widget tree will rebuild only one widget. Confirm behavior against the BlocSignal and Flutter versions in your project, and place a reactive read at the element whose build should depend on that value.
Best Value
Version and package context
The methods belong to bloc_signals_flutter, and the package changelog records their introduction in version 1.3.0. The API documentation consulted for these examples displayed version 1.3.2. Package APIs can change, so check the version resolved by your application and its current documentation before relying on a specific signature.
For the architectural framing and examples, see Randal L. Schwartz’s September 11, 2026 article.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
