Add a widget similar to SliverFillRemaining but allows for a minimum scroll amount

[Kypsis]

Changes from 0.1.9 to 0.1.10 break passing constraints to children:

class ExampleWidget extends StatelessWidget {

  @override
  Widget build(BuildContext context) {
    return MultiSliver(
      children: [
        SliverList(
                delegate: SliverChildBuilderDelegate((context, index) {
                  return ExampleItemWidget();
                }, childCount: exampleData.length),
              ),

        SliverFillRemaining(
            hasScrollBody: false,
            child: Container())
      ],
    );
  }
}

In 0.1.9 the SliverFillRemaining correctly filled the remaining space in the list if there are not enough items in the list to allow for the Multisliver to expand and fill the viewport in a CustomScrollView that already has a preceding flexible SliverAppBar. Or more succinctly 0.1.10 changes caused the child of SliverFillRemaining in MultiSliver to always have a height of 0.

[Kavantix]

I cannot reproduce your issue.
Could you provide a complete and minimal example?

[Kypsis]

Parent widget would be:

class ExampleParentScreen extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
          extendBody: true,
          backgroundColor: Themes.white,
          bottomNavigationBar: const NavigationWidget(),
          body: CustomScrollView(
            physics: BouncingScrollPhysics(),
            slivers: <Widget>[
              const ExampleAppBarWidget(),
              const ExampleWidget()
            ],
          ),
        );
      },
}

And ExampleAppBarWidget:

class ExampleAppBarWidget extends StatelessWidget {
  static const double collapsedHeight = 57.0;
  static const double expandedHeight = 465.0;

  const ExploreAppBarWidget();

  @override
  Widget build(BuildContext context) {
    return SliverPersistentHeader(
      pinned: true,
      delegate: _SliverAppBarDelegate(
          minHeight: collapsedHeight + MediaQuery.of(context).padding.top,
          maxHeight: expandedHeight + MediaQuery.of(context).padding.top),
    );
  }
}

class _SliverAppBarDelegate extends SliverPersistentHeaderDelegate {
  final double minHeight;
  final double maxHeight;

  _SliverAppBarDelegate({
    @required this.minHeight,
    @required this.maxHeight,
  });

  @override
  double get minExtent => minHeight;

  @override
  double get maxExtent => max(maxHeight, minHeight);

  @override
  Widget build(BuildContext context, double shrinkOffset, bool overlapsContent) {
    return Container(
          color: Colors.red
    );
  }

  @override
  bool shouldRebuild(_SliverAppBarDelegate oldDelegate) {
    return false;
  }
}

[Kavantix]

Using your code and having the child as a simple container:

class ExampleItemWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Container(
      height: 100,
      width: double.infinity,
      color: Colors.green,
      margin: const EdgeInsets.all(8),
    );
  }
}

I get this result when setting the fillremaining to blue so it seems to work

Are you using 0.1.10+1?

[Kypsis]

Now Imagine scrolling up so the appbar collapses: the red gets smaller, and the blue gets proportionally bigger. In 1.0.9 that was the behaviour if you didn't specify height to the Container (or SizedBox). In 1.1.10+1 the blue part wont resize so the appbar is not collapsable. You could give a scrollbody to the SliverFillRemaining but then the blue part would be viewport height, and the green list items would be scrollable offscreen. The intended behaviour is that if I have less items in the list than would fill the screen, then SliverFillRemaining would fill the missing part so the appbar is fully collapsable (otherwise the appbar would only be collapsable to the extent I have list items).

The use case would be a situation where I can add and remove items to and from the list. Or better example, I wouldn't want a situation where I only see partly expanded or collapsed appbar assuming I'm showing different content whether it is fully expanded or collapsed.

[Kavantix]

Sadly I must tell you that the behaviour 0.1.9 had was actually incorrect.
The current version behaves the same as if you didn't place the widgets inside a MuliSliver but directly inside the CustomScrollView.

I do actually have an adapted version of SliverFillRemaining in my private code (it's not open source ready) that allows you to specify a minimum amount of scroll that the SliverFillRemaining should provide.
If you want I can mail it to you and perhaps we can work together to get it included in this package.

[Kavantix]

I have emailed you the current version of the SliverFillRemainingWithMinimum widget
If you agree that it solves this issue we should start on a PR to add it to the package

[martipello]

how did this end?

[Kavantix]

@martipello it wasnt what he needed, feel free to open an issue if you’re running into something