It is not super-clear to me what the use case for such a sliver is. Can you elaborate (and possibly also update the documentation)? Why not throw all those slivers in a CustomScrollView?

@goderbauer I've added an example to the documentation. In the example the purpose it not to duplicate the same padding for every sliver. While for padding that would still be possible (but bad), for other cases it isn't: I've made a CrossAxisContraintSliver that, like ContraintBox, lets you constrain the maximum width of a child sliver and centring the child when needed. If you want to keep a group of slivers aligned by their left edge, you can't wrap them individually in CrossAxisContraintSliver.

Another kind of use cases is creating abstractions. Let's say I want to make a widget that is composed of a heading and a SliverList:

class ListItemGroup extends StatelessWidget {
  Widget build(BuildContext context) =>
    SliverGroup(
      slivers: [
        SliverToBoxAdapter(child: heading),
        SliverList(items),
    );
}

which is used like this:

CustomScrollView(
  slivers: [
    SliverAppBar(...),
    ListItemGroup(...),
    ListItemGroup(...),
  ],
);

That does sound like a valid use case. This could also live as an external package on pub, though. Is there any reason you feel like this belong in the framework?

It felt fundamental enough to be part of the framework, not very different from Column or Row. This one is to test the water, so to speak, I've also missed (and needed to create) sliver versions of Stack, LayoutBuilder, CustomPaint, ClipRRect. These seem like basic widgets that the framework should offer. On the other hand, you could argue that, since no one else has asked for them, maybe they aren't really needed.

In those cases it may be a good idea to implement them in an external package first. This would allow for fast iterations. When we add something to the framework we have to be sure that it has a reasonable stable API. If the package turns out to be popular, we can always pull it into the framework...

I tested this a few months ago during review. There were some cases where it broke, but I've incorporated bits of it into the larger project of Sliver[Flex, Group, Expanded, Spacer]. I should have a PR open for discussion & feedback soon.

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

Clicked comment & re-open instead of just comment. 😅

@spkersten do you cover for horizontal row case?
like putting two or more slivers beside of each other
it seems you only provide vertical column case for putting slivers there

@abdulghani I think a widget that groups slivers along the cross-axis direction would not be too hard to make; certainly easier than along the main-axis as I tried here. I might give it a try. I've been meaning to open source several missing sliver widgets, but I got a bit discouraged so it didn't materialise yet.

Hello @spkersten, I have a project where a SliverGroup is quite necessary. The page has a lot of different sections and wrapping all inside a StatefulWidget sounds a terrible idea. I have been using this as my custom SliverGroup. But I wonder if you think your solution is usable for a stable project. It would be very valuable to use, I think it is the most important sliver missing.

class SliverSection extends StatelessWidget {
  final List<Widget> slivers;

  const SliverSection({Key key, this.slivers}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return SliverToBoxAdapter(
      child: ShrinkWrappingViewport(
        offset: ViewportOffset.zero(),
        slivers: slivers,
      ),
    );
  }
}```

@jamesblasco We are using it quite extensively (for the modularisation reason you mention) in two of our released app. If you are putting simple slivers in it (lists, grids, slivertoboxadapters) it should work fine; fancier slivers (fill remaining, persistent header, special custom ones) might not work correctly in the group as that hasn't been tested to the same extent.

Thank you!! Perfect for the moment I am not using anything fancier inside.

We are using it quite extensively (for the modularisation reason you mention) in two of our released app.

@spkersten – sorry if I've missed it or misunderstood, is your sliver package available on pub.dev?

@scopendo I never got around making a package. However, there is sliver_tools that contains a widget that seems to offer the same functionality.

If you give me your permission @spkersten to use this code, I would be happy to use it with some modifications to build a package out of it, also adapt it for null-safety and add tests.

I have been using it for some projects and I find it super useful