DEV Community 36m ago

Taming Flutter Infinite Scroll (Part 2): Turning ScrollController into a Reactive State Machine with CubitSignalMixin

We need to reformat the given raw article body into clean Markdown, with paragraphs, headings, lists, code blocks, preserving facts. No extra intro/conclusion. No repeating title as heading. Output only reformatted article body.

We must break into short paragraphs, add section headings where topic shifts. Use bullet/numbered lists for enumerations. Use inline code or fenced code blocks for code, commands, identifiers.

We must preserve every fact, name, number, quotation exactly. Lightly polish wording for flow and grammar but not add info.

We need to identify sections: The article seems to have parts:

Introduction: "The Infinite Scroll Rite of Passage In Part 1: ..." maybe start.
Then discussion of third-party packages.
Then "What if you did not need a third-party pagination package at all?" etc.
Then "🧱 Dart's Single-Inheritance Wall"
Then "🧬 How Composable Mixins Break the Wall"
Then "📐 Pattern A: The Reactive PagingScrollController (Separation of Concerns)" with code block.
Then "💡 The extentAfter Secret: Why Pixels Beat Percentages"
Then "The Superpower of Automatic De-duplication"
Then "⚡ Pattern B: The Self-Paging Domain Controller (Zero-Bridge Architecture)" with code block.
Then "🎨 The Flutter UI: A 100% StatelessWidget" with code block.

We need to ensure headings using ##.

We must not repeat article title as heading. So we start directly with content.

We need to break paragraphs appropriately.

Let's extract paragraphs.

Original article text (I'll copy):

"The Infinite Scroll Rite of Passage In Part 1: Taming Flutter Infinite Scroll: Why 3 Lines of async* Missed the Point, and How BlocSignal Fixes It , we explored why wrapping mutable state in async* generators and StreamIterator cracks under pressure when users rapidly fling a list. We demonstrated how BlocSignal ’s streamless droppable() transformer solves thumb-flinging race conditions synchronously at the event boundary without Rx streams or microtask lag. Yet, even after solving event concurrency with a pure BLoC, many Flutter developers are left with a nagging architectural itch. Search pub.dev for "infinite scroll" or "pagination" , and you will find dozens of packages- infinite_scroll_pagination , lazy_load_scrollview , flutter_pagewise , loadmore . It is practically a rite of passage for every Flutter developer to install at least one of them. Why do these packages exist in such numbers? Because implementing pagination with standard Flutter controllers requires tedious widget-level plumbing: Creating a StatefulWidget . Instantiating and maintaining an instance of ScrollController . Subscribing to scroll metrics with _scrollController.addListener(_onScroll) in initState . Remembering to call removeListener and _scrollController.dispose() in dispose() . Manually calculating viewport extents ( offset >= maxScrollExtent * 0.9 ). Gluing the scroll trigger to a state management call ( context.read<PostsBloc>().add(...) ). Unfortunately, the third-party pagination packages on pub.dev often extract a heavy architectural tax: They hijack your widget tree : They force you to replace standard Flutter widgets with proprietary wrappers like PagedListView , fighting your slivers, custom scroll physics, and layout styling. They invent competing controllers : They introduce bespoke paging controllers alongside your existing BLoCs or Notifiers, creating two competing sources of truth that you must manually synchronize. They attempt to solve concurrency in the UI : They try to debounce or guard fetch requests inside widget lifecycle callbacks instead of at the architectural event boundary. What if you did not need a third-party pagination package at all? What if Flutter's standard ScrollController could itself be your reactive state container? Let us examine why that was historically impossible in Dart-and how composable mixins change everything. 🧱 Dart's Single-Inheritance Wall Why couldn't Flutter's ScrollController just extend BlocSignal or CubitSignal ? In Dart, a class can extend only one superclass. Flutter's ScrollController extends ChangeNotifier (which implements Listenable ). If you want a class to also be a CubitSignal or BlocSignal , Dart's single-inheritance constraint stops you dead in your tracks: // ❌ Impossible in Dart (Multiple inheritance is forbidden): class PaginatedPostsController extends ScrollController , BlocSignal < PostsEvent , PostsState > { // Dart analyzer error: Each class can have only one superclass. } Historically, this constraint forced developers into two unsatisfying compromises: The Proxy / Wrapper Anti-Pattern : Creating a wrapper class that held an internal _bloc reference, requiring tedious method forwarding and lifecycle delegation. The Dual-Lifecycle Trap : Managing a ScrollController and a PostsBloc as separate objects in the widget tree, gluing them together with initState listeners and cleaning both up in dispose() . With CubitSignalMixin and BlocSignalMixin in bloc_signals , that single-inheritance wall is demolished. 🧬 How Composable Mixins Break the Wall Because BlocSignal has a minimal, highly disciplined API contract, mixing it into arbitrary classes introduces zero namespace collisions: ┌────────────────────────────────────────────────────────────────────────┐ │BlocSignal Mixin Architecture │ ├────────────────────────────────┬───────────────────────────────────────┤ │ Mixin│ Capabilities Added│ ├────────────────────────────────┼───────────────────────────────────────┤ │ CubitSignalMixin<StateType>│ state, stateValue, emit(newState),│ ││ equals(), createEffect(), close() │ ├────────────────────────────────┼───────────────────────────────────────┤ │ BlocSignalMixin<Event, State>│ on<E>(), concurrency transformers │ ││ (droppable, restartable), add(event)│ └────────────────────────────────┴───────────────────────────────────────┘ When a class adopts CubitSignalMixin<StateType> , it implements BlocSignalBase<StateType> . It gains: 0ms synchronous reactive signals ( state ). Direct synchronous state value access ( stateValue ). Automatic de-duplication ( emit(newState) drops transitions when newState == currentState ). Reactive observer tracking and lifecycle management. And when combined with BlocSignalMixin<Event, StateType> , it gains full event-driven execution with streamless transformers like droppable() and restartable() . This unlocks two clean architectural patterns for infinite scroll. 📐 Pattern A: The Reactive PagingScrollController (Separation of Concerns) If your architectural philosophy demands that your domain business logic remain 100% pure Dart (with zero imports of package:flutter/widgets.dart ), you can turn ScrollController into a focused, reactive boolean signal: import 'package:bloc_signals/bloc_signals.dart' ; import 'package:flutter/widgets.dart' ; /// A ScrollController that is also a CubitSignal emitting whether /// the scroll viewport is within [threshold] pixels of the bottom. class PagingScrollController extends ScrollController with CubitSignalMixin < bool > { PagingScrollController ({ this . threshold = 200.0 }) { // 1. Initialize the CubitSignalMixin with initial state initCubitSignal ( initialState: false ); // 2. Listen to scroll metrics internally addListener ( _onScrollChanged ); } /// Remaining scroll extent threshold in logical pixels (default: 200.0). final double threshold ; bool _isControllerDisposed = false ; void _onScrollChanged () { if ( ! hasClients ) return ; // position.extentAfter returns the exact remaining pixels after the viewport! final isNearBottom = position . extentAfter < = threshold ; // 3. emit() automatically de-duplicates: // Only triggers subscribers when the boolean flips between false and true! emit ( isNearBottom ); } @override void dispose () { if ( _isControllerDisposed ) return ; _isControllerDisposed = true ; removeListener ( _onScrollChanged ); close (); super . dispose (); } @override Future < void > close () async { if ( ! _isControllerDisposed ) { _isControllerDisposed = true ; removeListener ( _onScrollChanged ); super . dispose (); } await super . close (); } } 💡 The extentAfter Secret: Why Pixels Beat Percentages Notice line 20: final isNearBottom = position . extentAfter < = threshold ; Most Flutter pagination tutorials write something like: // ⚠️ The percentage trap: final isBottom = offset > = maxScrollExtent * 0.9 ; Calculating a percentage (such as 0.9 ) creates an erratic user experience: On a short list of 1,000 pixels, 90% triggers when you are 100 pixels from the bottom. On a long list of 50,000 pixels, 90% triggers when you are 5,000 pixels from the bottom-downloading pages far in advance that the user may never scroll to! Flutter's ScrollPosition.extentAfter returns the exact quantity of content in logical pixels remaining after the viewport's trailing edge ( math.max(maxScrollExtent - pixels, 0.0) ). Using position.extentAfter <= 200.0 : Provides a consistent lead time : You always start fetching the next page when the user is ~2 items away from the bottom, regardless of whether the list has 10 items or 10,000 items. Eliminates calculation boilerplate : No multiplying maxScrollExtent * 0.9 , no reading offset , and no bounds-checking when a list is empty. It is a single, clean comparison. The Superpower of Automatic De-duplication Notice line 27: emit(isNearBottom); . As a user scrolls vigorously near the bottom, scroll notifications fire dozens of times across 91%, 93%, 97%, and 99% of the viewport. In naive Flutter code, this requires manual boolean guards to prevent triggering duplicate actions. With CubitSignalMixin , de-duplication is automatic . Because emit() checks newState == currentState , calling emit(true) twenty times in a row produces zero spurious signal updates. The signal fires exactly once when crossing the threshold downward, and exactly once when scrolling back upward! Connecting this to your domain PostsBloc requires just a single declarative effect: pagingController . createEffect (() { if ( pagingController . stateValue ) { postsBloc . add ( const PostsFetched ()); } }); The domain BLoC remains completely independent of Flutter, while the widget avoids doing manual scroll extent arithmetic. ⚡ Pattern B: The Self-Paging Domain Controller (Zero-Bridge Architecture) Now, let us take the architectural leap. What if you do not want a separate controller, a separate BLoC, and glue code between them? What if your controller is the ScrollController , and your controller is the BlocSignal ? Here is PaginatedPostsController : import 'dart:async' ; import 'package:bloc_signals/bloc_signals.dart' ; import 'package:flutter/widgets.dart' ; import '../models/post.dart' ; class PaginatedPostsController extends ScrollController with CubitSignalMixin < PostsState >, BlocSignalMixin < PostsEvent , PostsState > { PaginatedPostsController ({ this . threshold = 200.0 , required PostRepository repository , }) : _repository = repository { // 1. Initialize CubitSignal state initCubitSignal ( initialState: const PostsState ()); // 2. Streamless concurrency: drop overlapping scroll triggers on < PostsFetched >( _onPostsFetched , transformer: droppable (), ); // 3. Streamless concurrency: cancel and restart on search query change on < PostsSearchChanged >( _onPostsSearchChanged , transformer: restartable (), ); // 4. Controller listens to its own scroll geometry! addListener ( _onScrollChanged ); } /// Remaining scroll extent threshold in logical pixels (default: 200.0). final double threshold ; final PostRepository _repository ; bool _isControllerDisposed = false ; void _onScrollChanged () { if ( ! hasClients ) return ; // Single, clean extentAfter check: if ( position . extentAfter < = threshold ) { add ( const PostsFetched ()); } } Future < void > _onPostsFetched ( PostsFetched event , void Function ( PostsState ) emit , ) async { if ( stateValue . hasReachedMax ) return ; try { if ( stateValue . status == PostsStatus . initial ) { final posts = await _repository . fetchPosts ( startIndex: 0 , count: 10 , query: stateValue . searchQuery , ); return emit ( stateValue . copyWith ( status: PostsStatus . success , posts: posts , hasReachedMax: false , )); } final posts = await _repository . fetchPosts ( startIndex: stateValue . posts . length , count: 10 , query: stateValue . searchQuery , ); emit ( posts . isEmpty ? stateValue . copyWith ( hasReachedMax: true ) : stateValue . copyWith ( status: PostsStatus . success , posts: [.. . stateValue . posts , .. . posts ], hasReachedMax: stateValue . posts . length + posts . length > = 30 , )); } catch ( _ ) { emit ( stateValue . copyWith ( status: PostsStatus . failure )); } } Future < void > _onPostsSearchChanged ( PostsSearchChanged event , void Function ( PostsState ) emit , ) async { final posts = await _repository . fetchPosts ( startIndex: 0 , count: 10 , query: event . query , ); emit ( stateValue . copyWith ( status: PostsStatus . success , posts: posts , hasReachedMax: false , searchQuery: event . query , )); } @override void dispose () { if ( _isControllerDisposed ) return ; _isControllerDisposed = true ; removeListener ( _onScrollChanged ); close (); super . dispose (); } @override Future < void > close () async { if ( ! _isControllerDisposed ) { _isControllerDisposed = true ; removeListener ( _onScrollChanged ); super . dispose (); } await super . close (); } } Look at what this class accomplishes: It is a ScrollController : You can pass it directly to ListView.builder(controller: controller) . It is a BlocSignalBase : You can pass it directly to BlocSignalBuilder or provide it with BlocSignalProvider . It manages its own event dispatch : It inspects its own scroll offset and calls add(const PostsFetched()) . It governs its own concurrency : transformer: droppable() guarantees that rapid thumb flings while a network request is in-flight are synchronously ignored on the same frame. 🎨 The Flutter UI: A 100% StatelessWidget Now observe what happens to the Flutter UI layer: import 'package:bloc_signals_flutter/bloc_signals_flutter.dart' ; import 'package:flutter/material.dart' ; import '../controllers/paginated_posts_controller.dart' ; class SelfPagingPostsView extends StatelessWidget { const SelfPagingPostsView ({ super . key }); @override Widget build ( BuildContext context ) { final controller = context . read < PaginatedPostsController >(); return Scaffold ( appBar: AppBar ( title: const Text ( 'Self-Paging Controller (Stateless)' ), bottom: PreferredSize ( preferredSize: const Size . fromHeight ( 60 ), child: Padding ( padding: const EdgeInsets . symmetric ( horizontal: 16.0 , vertical: 8.0 ), child: TextField ( decoration: const InputDecoration ( hintText: 'Search posts...' , prefixIcon: Icon ( Icons . search ), border: OutlineInputBorder (), ), onChanged: ( query ) { controller . add ( PostsSearchChanged ( query )); }, ), ), ), ), body: BlocSignalBuilder < PaginatedPostsController , PostsState >( builder: ( context , state ) { switch ( state . status ) { case PostsStatus . initial : return const Center ( child: CircularProgressIndicator ()); case PostsStatus . failure : return const Center ( child: Text ( 'Failed to load posts' )); case PostsStatus . success : if ( state . posts . isEmpty ) { return const Center ( child: Text ( 'No posts found.' )); } return ListView . builder ( controller: controller , // Plugs directly into Flutter's native ListView! itemCount: state . hasReachedMax ? state . posts . length : state . posts . length + 1 , itemBuilder: ( c

The text ends abruptly at "itemBuilder: ( c". Probably cut off. We must preserve exactly as given, not add missing parts. So we keep that incomplete line as is.

Now we need to format.

We'll create sections:

Introduction (maybe not needed but we can start with first paragraph). However rule: do not repeat article title as heading. We can add headings for topic shifts.

Let's identify shifts:

Opening paragraph up to "Let us examine why that was historically impossible in Dart-and how composable mixins change everything. 🧱 Dart's Single-Inheritance Wall"
Then section about Dart's Single-Inheritance Wall (including code block).
Then "🧬 How Composable Mixins Break the Wall" (including table).
Then "📐 Pattern A: The Reactive PagingScrollController (Separation of Concerns)" (including code block).
Then "💡 The extentAfter Secret: Why Pixels Beat Percentages"
Then "The Superpower of Automatic De-duplication"
Then "⚡ Pattern B: The Self-Paging Domain Controller (Zero-Bridge Architecture)" (including code block and explanation).
Then "🎨 The Flutter UI: A 100% StatelessWidget" (including code block).

We'll also need bullet lists for enumerations: e.g., list of packages, list of plumbing steps, list of architectural tax points, list of capabilities added (maybe we can keep table but also bullet list). The instruction: Use bullet or numbered lists for enumerations. So we should convert enumerations to bullet lists.

We have enumerations:

"Search pub.dev for "infinite scroll" or "pagination" , and you will find dozens of packages- infinite_scroll_pagination , lazy_load_scrollview , flutter_pagewise , loadmore ."
"Creating a StatefulWidget . Instantiating and maintaining an instance of ScrollController . Subscribing to scroll metrics with _scrollController.addListener(_onScroll) in initState . Remembering to call removeListener and _scrollController.dispose() in dispose() . Manually calculating viewport extents ( offset >= maxScrollExtent * 0.9 ). Gluing the scroll trigger to a state management call ( context.read<PostsBloc>().add(...) )."
"Unfortunately, the third-party pagination packages on pub.dev often extract a heavy architectural tax: They hijack your widget tree : They force you to replace standard Flutter widgets with proprietary wrappers like PagedListView , fighting your slivers, custom scroll physics, and layout styling. They invent competing controllers : They introduce bespoke paging controllers alongside your existing BLoCs or Notifiers, creating two competing sources of truth that you must manually synchronize. They attempt to solve concurrency in the UI : They try to debounce or guard fetch requests inside widget lifecycle callbacks instead of at the architectural event boundary."
The table of mixin capabilities: we could keep as a table or convert to bullet list. The instruction says use bullet or numbered lists for enumerations; tables are okay but not required. We can keep the table as is (it's a visual representation). Might be okay.
In Pattern A code block we have comments enumerating steps: "1. Initialize the CubitSignalMixin with initial state", "2. Listen to scroll metrics internally". Could keep as comments.
In Pattern B code block we have steps enumerated similarly.

We'll preserve code blocks exactly as given, but we need to ensure they are fenced with triple backticks and language dart.

We need to preserve every fact, name, number, quotation exactly. So we must not change spacing inside code? We can keep as is but ensure code fences.

We need to lightly polish wording for flow and grammar: we can adjust punctuation, fix spacing, but not change meaning.

Let's produce markdown.

We'll start with first paragraph:

We need to break into short paragraphs. Let's split after each major idea.

Paragraph 1: Up to "... microtask lag."

Paragraph 2: "Yet, even after solving event concurrency with a pure BLoC, many Flutter developers are left with a nagging architectural itch."

Paragraph 3: "Search pub.dev for "infinite scroll" or "pagination" , and you will find dozens of packages- infinite_scroll_pagination , lazy_load_scrollview , flutter_pagewise , loadmore . It is practically a rite of passage for every Flutter developer to install at least one of them. Why do these packages exist in such numbers? Because implementing pagination with standard Flutter controllers requires tedious widget-level plumbing: Creating a StatefulWidget . Instantiating and maintaining an instance of ScrollController . Subscribing to scroll metrics with _scrollController.addListener(_onScroll) in initState . Remembering to call removeListener and _scrollController.dispose() in dispose() . Manually calculating viewport extents ( offset >= maxScrollExtent * 0.9 ). Gluing the scroll trigger to a state management call ( context.read<PostsBloc>().add(...) )."

Paragraph 4: "Unfortunately, the third-party pagination packages on pub.dev often extract a heavy architectural tax: They hijack your widget tree : They force you to replace standard Flutter widgets with proprietary wrappers like PagedListView , fighting your slivers, custom scroll physics, and layout styling. They invent competing controllers : They introduce bespoke paging controllers alongside your existing BLoCs or Notifiers, creating two competing sources of truth that you must manually synchronize. They attempt to solve concurrency in the UI : They try to debounce or guard fetch requests inside widget lifecycle callbacks instead of at the architectural event boundary."

Paragraph 5: "What if you did not need a third-party pagination package at all? What if Flutter's standard ScrollController could itself be your reactive state container? Let us examine why that was historically impossible in Dart-and how composable mixins change everything."

Now heading for Dart's Single-Inheritance Wall.

We'll add ## Dart's Single-Inheritance Wall

Then paragraph: "Why couldn't Flutter's ScrollController just extend BlocSignal or CubitSignal ? In Dart, a class can extend only one superclass. Flutter's ScrollController extends ChangeNotifier (which implements Listenable ). If you want a class to also be a CubitSignal or BlocSignal , Dart's single-inheritance constraint stops you dead in your tracks:"

Then code block.

Then paragraph: "Historically, this constraint forced developers into two unsatisfying compromises: The Proxy / Wrapper Anti-Pattern : Creating a wrapper class that held an internal _bloc reference, requiring tedious method forwarding and lifecycle delegation. The Dual-Lifecycle Trap : Managing a ScrollController and a PostsBloc as separate objects in the widget tree, gluing them together with initState listeners and cleaning both up in dispose() . With CubitSignalMixin and BlocSignalMixin in bloc_signals , that single-inheritance wall is demolished."

Now heading for How Composable Mixins Break the Wall.

How Composable Mixins Break the Wall

Paragraph: "Because BlocSignal has a minimal, highly disciplined API contract, mixing it into arbitrary classes introduces zero namespace collisions:" Then we can keep the table as is (maybe as a markdown table). We'll need to format the table properly.

The original table uses box-drawing characters; we can keep as a code block? But it's a table; we can convert to markdown table.

Let's reconstruct:

Mixin	Capabilities Added
CubitSignalMixin<StateType>	state, stateValue, emit(newState), equals(), createEffect(), close()
BlocSignalMixin<Event, State>	on<E>(), concurrency transformers (droppable, restartable), add(event)

We'll preserve exactly the content.

Then paragraph: "When a class adopts CubitSignalMixin<StateType> , it implements BlocSignalBase<StateType> . It gains: 0ms synchronous reactive signals ( state ). Direct synchronous state value access ( stateValue ). Automatic de-duplication ( emit(newState) drops transitions when newState == currentState ). Reactive observer tracking and lifecycle management. And when combined with BlocSignalMixin<Event, StateType> , it gains full event-driven execution with streamless transformers like droppable() and restartable() . This unlocks two clean architectural patterns for infinite scroll."

Now heading for Pattern A.

Pattern A: The Reactive PagingScrollController (Separation of Concerns)

Paragraph: "If your architectural philosophy demands that your domain business logic remain 100% pure Dart (with zero imports of package:flutter/widgets.dart ), you can turn ScrollController into a focused, reactive boolean signal:"

Then code block.

We need to ensure code block is fenced with ```dart and content exactly as given.

We must preserve the code exactly, including spaces and line breaks. Let's copy the code block from the article:

import 'package:bloc_signals/bloc_signals.dart' ;
import 'package:flutter/widgets.dart' ;
/// A ScrollController that is also a CubitSignal emitting whether ///
the scroll viewport is within [threshold] pixels of the bottom.
class PagingScrollController extends ScrollController with CubitSignalMixin < bool > {
PagingScrollController ({ this . threshold = 200.0 }) {
// 1. Initialize the

Read on DEV Community ↗ ← Back to News

Taming Flutter Infinite Scroll (Part 2): Turning ScrollController into a Reactive State Machine with CubitSignalMixin

Introduction (maybe not needed but we can start with first paragraph). However rule: do not repeat article title as heading. We can add headings for topic shifts.

How Composable Mixins Break the Wall

Pattern A: The Reactive PagingScrollController (Separation of Concerns)

Comments