Added optional before and after slivers to sandwich the list.

[wiradikusuma]

Sometimes you have your own slivers in addition to the list, e.g. a SliverPersistentHeader on top and SliverToBoxAdapter at the bottom. These 2 properties allow you to do that.

Dart version bumped to 2.2.2 to make use of the spread operator.

[TatsuUkraine]

thanks for the PR)

I'm actually not sure if these changes are needed. This package is about sticky headers, for custom scrollable containers you can always use widget items independently and build any scrollable container as you want

[TatsuUkraine]

like this one StickyListItem that can be used anywhere within the scrollable widget

[wiradikusuma]

You meant to say since InfiniteList is just a thin wrapper of CustomScrollView, I can directly use StickyListItem in my own CustomScrollView?

I was just thinking that when you add more stuff to InfiniteList (reverse, line divider, etc) and it becomes a "thicker" wrapper, I would rather use this library than copy-pasting those new features to my half-baked widget.

What do you think?

[TatsuUkraine]

You meant to say since InfiniteList is just a thin wrapper of CustomScrollView, I can directly use StickyListItem in my own CustomScrollView?

yep, InfiniteList was designed to simplify multi-directional render of items, but nothing more.

I was just thinking that when you add more stuff to InfiniteList (reverse, line divider,

I agree that divider might be helpful since it's part of the overall list. As for reverse key, it also could be helpful, but Flutter has some strange behavior when it comes to sliver positions in reverse mode) I was trying to add it multiple times, last time I was looking if anything changes in 1.12 or 1.17, and slivers still had some fancy position coordinates) maybe with 1.20 it fixed, haven't looked at it yet

[TatsuUkraine]

@wiradikusuma I just published v3 for 1.20 flutter support, so I changed base branch for this PR

[TatsuUkraine]

I'm thinking, what if instead of making this class full of different keys, just change some of the properties to make them public? For instance slivers keys and so on, in that way you can just extent this class and adjust any key you want

[wiradikusuma]

I thought of suggesting that initially, but I believe Flutter's philosophy for widgets is composition over inheritance.

[TatsuUkraine]

Flutter's philosophy for widgets is composition over inheritance.

Well yes, composition over inheritance is something that flutter prefer, but it's not writen in the stone. You can actually find some of the widgets out of the box, that was made for extend rather than for composition.

But, adding bunch of generic properties that doesn't fit to the responsibility of the widget is less attractive than extend) I would probably think about something more flexible like delegate rather than params