Updated example and v2 of lazy_load_scrollview

[stargazing-dino]

Hello ! I didn't know of the existence of this package and ended up creating listview notifier similar to this but slightly different. In any case, I'd like to offer it up as a PR. To improve I took both my ideas and your ideas and kind of squashed them together as well as implemented a few things from the issues here.

Here are a few things the new:

• lazyloadscrollview takes an optional ScrollController now that will work in place of bubbling notifier events (this is useful to avoid predicates)
• Added notificationPredicate Check for notification level depth #15
• Added an example on how to add animation when reached the end No animation when reached to bottom. #2
• lazyloadscrollview can now work in both directions of a listview
• Added debounce timer that will prevent the callback from firiing a bunch of times

Breaking change:

• the lazyloadscrollview takes a builder instead of a child. This builder passes through isLoadingBefore and isLoadingAfter that tell the user when the respective async op is running.
• Renamed onEndOfPage to to onLoadAfter

I'd love to get your opinion on this big change. Leaving it as a draft for now

[QuirijnGB]

Hey Thanks for this and sorry for the late response. Ill have a look this week!

[QuirijnGB]

Thanks for you contributions so far! I've just added a couple of questions

[QuirijnGB]

What would you expect to do with the error?

[stargazing-dino]

It's user convenience. I have a package called async_button_builder that wraps a user's callback and handles its various states. I found that if I don't use a completer and their function errors, I can rethrow but that won't give them the stackTrace. It'll also throw at my callsite of their function too rather than in their original function which was kinda lame. It's a gut assumption right now as I haven't tested, but I think if their load more functions error, the same will happen and they'll get no helpful stacktrace (again, not sure tho). I'll test on weekend

[stargazing-dino]

Ah, nvm, just checked real quick. It handles the error correctly. I'll remove that TODO:

[stargazing-dino]

I did forget though that if it errors, it won't call anything afterward which means the loading state won't be reset. Here's before:

await widget.onLoadAfter?.call().timeout(widget.timeout);
setState(() => isLoadingAfter = false);

after:

await widget.onLoadAfter?.call().timeout(widget.timeout).whenComplete(
  () {
    setState(() => isLoadingAfter = false);
  },
);

[stargazing-dino]

6e41d01

[QuirijnGB]

If this is likely and undesired behaviour, can we add assertions in the constructor to prevent this from happening?

[stargazing-dino]

Hmm, I think I wrote that before the predicate. How does this sound instead:

/// The [Scrollable] should be a direct child of this builder for us to listen
/// to bubbling events. If it is not the direct child, you must further specify
/// a predicate in order to find it in the descendents or, if there are no other
/// scrollables, set [ignoreDepth] to true. If you'd like to avoid a
/// predicate, you may also provide an optional [ScrollController].

I don't think we can do an assertion either of a child of a builder because it'd need to be built first too. But that comment should clear things up.

[QuirijnGB]

Could you elaborate on the concern here?

[stargazing-dino]

Ah yeah, this was weird. So I think even if I set the predicate to the right layer where the descendant scrollable was, I couldn't get the thing to work (without using a scrollcontroller). I actually think the Scrollbar is handling the notifications and not allowing them to bubble (by returning false in their NotificationListener onNotification). Can you confirm that it worked previously with your implementation (wrt Scrollbar specifically)?

[QuirijnGB]

I have not forgotten about this! Ill get to it soon