Feature request: MultiSliver.builder

[cgestes]

I would like to make a view like the schedule view of a calendar app.

A list view that is infinite in both direction, that can be indexed and that can have sticky header.

I am trying to adapt https://pub.dev/packages/indexed_list_view to support sliver children, I have thinking of returning MultiSliver instead of a SliverFixedExtentList, to be able to put SliverStickyHeader into the indexedlist.

Yeah not so simple !

So I would need a MultiSliver with a builder function.

If you have any feedback, this is very welcome :)

I looked everywhere and couldn't find anything.. maybe I am missing something obvious.

Thanks

[Kavantix]

Can you elaborate on what you would expect a MultiSliver.builder to be?

[LucasAschenbach]

I think he is suggesting to add an option to also provide a sliver builder function instead of the children argument. This is sometimes preferred, or even necessary, as the number of children grows since instantiating all children on the first build can be very expensive or even impossible in case of an infinite list. With a builder each child is only instantiated once it needs to be painted. (Similar to SliverChildListDelegate vs. SliverChildBuilderDelegate)

[Kavantix]

@LucasAschenbach thanks for attempting to clarify, however that part I understood. I should have been a bit clearer in my question.

The question I meant was: How would you expect a MultiSliver.builder to work. Because slivers are always built since their position in the list doesn’t necessarily mean that they will be drawn after the item before it. For instance, sticky headers work because they always get the chance to layout even if they are way earlier in the list.
I do have a ticket open #10 which proposes an idea to manually optimize expensive slivers.

[cgestes]

We can close 😁
I did differently. I don't know enough about the subject to understand the issue even less to propose a solution.

[cgestes]

Same as it is but with a builder pattern, like Listview.builder. it's possible I am missing a part of the puzzle and what I want to achieve is not possible like that :')

…

On Fri, Mar 11, 2022 at 9:19 PM Pieter van Loon ***@***.***> wrote: Can you elaborate on what you would expect a MultiSliver.builder to be? — Reply to this email directly, view it on GitHub <#44 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAL75MGWC5DMGRCEVXOG2TU7OTF7ANCNFSM5QQRZT5Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[Kavantix]

@cgestes perhaps I can help come up with a solution for your specific problem, I still feel a builder version of MultiSliver is not possible with the current flutter implementation of Slivers

[cgestes]

I believe it is ok to leave it closed :)

I have not enough context any more to provide any useful information.

I dont even remember how I sorted out my issue in the end.

Thank you @Kavantix .

[cbarlow26]

Not sure if I should comment here or create a new issue to continue the discussion.

You might be right about Flutter's implementation of slivers and that it's not possible to create MultiSliver with a builder delegate, but then, how does SliverList accomplish this? The problem with SliverList is that it expects the builder to return render boxes and we need to return render slivers.

What are your thoughts?

[Kavantix]

@cbarlow26 the problem you point out is exactly the difference that makes it not possible to do it the way SliverList does it. What SliverList basically does is only build a small subset of the children, but for slivers you always need to build all of them so there would be no time saved

[cbarlow26]

@Kavantix Thank you for the explanation. That's very interesting.

In my case, and maybe others as well, I'm trying mix render boxes and render slivers inside a single SliverList. It's much easier to leverage SliverList's builder delegate than to roll my own widget that listens to scrolling events and then manually constructs a list of [SliverPinnedHeader, SliverList, SliverPinnedHeader, SliverList, etc...].

Specifically, I'm using PagedSliverList from the infinite_scroll_pagination package and I want my items to have pinned headers. Internally, PagedSliverList uses a single SliverList that is updated when new items are fetched.

Any insights or solutions that you may have would be greatly appreciated. Thanks!

[Kavantix]

How many of these pairs of sliver list and pinned header do you have?

[cbarlow26]

@Kavantix The list is fetched from a database and is infinite. Each call to the database retrieves a "page" worth of items which, in my case, is anywhere from 3 to 10 items. The SliverList only contains 3 to 5 pages at one time; the one currently visible and some buffered pages at the beginning and end. So, there would be 3 to 5 pairs of pinned headers and sliver lists at any one time, depending on how I configure page buffering.

The items are built as soon as they're retrieved from the database, so for me, I think it's ok if all the silvers are built. I think SliverList might do something similar. It seems to call the build delegate until the viewport is full. Just guessing.

Anyway, thanks!

[cbarlow26]

I may have misspoke. PagedSliverList may keep the entire list of items and rebuild the SliverList when new items are added and just buffer the end of the list.

[Kavantix]

You are correct about sliverlist building only what it needs, Listview is just a sliverlist but with a scrollview already configured around it.

But if you are ok with building all the widgets, what is the builder version than useful for?
you could simply build the pairs of slivers in a for look right?

[cbarlow26]

The advantage of the SliverList builder version is that it automatically asks the builder for more items when the view scrolls to the end of the list. This is when I can fetch more items from the db. The non-builder version has no scrolling callbacks, so I'd have to create a custom widget that mimics this behavior. Maybe it's not as hard as I think, but I'd rather not reinvent the wheel.

I was hoping to simply replace my use of SliverList with MultiSliver, but I see your point about having to build all the slivers up front. That's unexpected behavior when using a builder method. My use case might be unique.

Thanks for helping me think through this. I'll post back if I come up with something clever.