SliverChildDelegate class abstract

A delegate that supplies children for slivers.

Many slivers lazily construct their box children to avoid creating more children than are visible through the Viewport. Rather than receiving their children as an explicit List, they receive their children using a SliverChildDelegate.

It's uncommon to subclass SliverChildDelegate. Instead, consider using one of the existing subclasses that provide adaptors to builder callbacks or explicit child lists.

Child elements' lifecycle

Creation

While laying out the list, visible children's elements, states and render objects will be created lazily based on existing widgets (such as in the case of SliverChildListDelegate) or lazily provided ones (such as in the case of SliverChildBuilderDelegate).

Destruction

When a child is scrolled out of view, the associated element subtree, states and render objects are destroyed. A new child at the same position in the sliver will be lazily recreated along with new elements, states and render objects when it is scrolled back.

Destruction mitigation

In order to preserve state as child elements are scrolled in and out of view, the following options are possible:

• Moving the ownership of non-trivial UI-state-driving business logic out of the sliver child subtree. For instance, if a list contains posts with their number of upvotes coming from a cached network response, store the list of posts and upvote number in a data model outside the list. Let the sliver child UI subtree be easily recreate-able from the source-of-truth model object. Use StatefulWidgets in the child widget subtree to store instantaneous UI state only.

• Letting KeepAlive be the root widget of the sliver child widget subtree that needs to be preserved. The KeepAlive widget marks the child subtree's top render object child for keepalive. When the associated top render object is scrolled out of view, the sliver keeps the child's render object (and by extension, its associated elements and states) in a cache list instead of destroying them. When scrolled back into view, the render object is repainted as-is (if it wasn't marked dirty in the interim).

  This only works if the SliverChildDelegate subclasses don't wrap the child widget subtree with other widgets such as AutomaticKeepAlive and RepaintBoundary via addAutomaticKeepAlives and addRepaintBoundaries.

• Using AutomaticKeepAlive widgets (inserted by default in SliverChildListDelegate or SliverChildListDelegate). AutomaticKeepAlive allows descendant widgets to control whether the subtree is actually kept alive or not. This behavior is in contrast with KeepAlive, which will unconditionally keep the subtree alive.

  As an example, the EditableText widget signals its sliver child element subtree to stay alive while its text field has input focus. If it doesn't have focus and no other descendants signaled for keepalive via a KeepAliveNotification, the sliver child element subtree will be destroyed when scrolled away.

  AutomaticKeepAlive descendants typically signal it to be kept alive by using the AutomaticKeepAliveClientMixin, then implementing the AutomaticKeepAliveClientMixin.wantKeepAlive getter and calling AutomaticKeepAliveClientMixin.updateKeepAlive.

Using more than one delegate in a Viewport

If multiple delegates are used in a single scroll view, the first child of each delegate will always be laid out, even if it extends beyond the currently viewable area. This is because at least one child is required in order to estimateMaxScrollOffset for the whole scroll view, as it uses the currently built children to estimate the remaining children's extent.

See also:

• SliverChildBuilderDelegate, which is a delegate that uses a builder callback to construct the children.
• SliverChildListDelegate, which is a delegate that has an explicit list of children.