Open hasanmhallak opened 1 year ago
Reproducible using the code sample provided above.
I'm having this exact issue, and about..
I'm not sure if that's intended or not.
..can we get a short answer about this question?
I'm heavily relying on the ability to return null
on paginated / infinite view scroll lists (but also with slivers, grids, etc.). This is great because returning null
effectively means "ok, no more items in this direction".
This is an extremely common practice when it comes to infinite scrollable paginated views with Riverpod, btw
Hey @lucavenir. While the approach of implementing a fetch-on-demand/scroll using the builder
might be effective, there could be alternative strategies worth considering.
For a temporary fix, you can disable autoDispose
in your notifier. see the original issue here
One alternative approach could be to rely on the scrolling position rather than the builder
. The initial method fetches data only when the user reaches the end of the list, which may result in a suboptimal user experience. A suggestion is to consider listening to scrolling notifications and fetching a new page when the user reaches, for example, the last third of the last fetched page. This way, the user won't even notice that new data is being retrieved.
In terms of handling scrolling positions, this would involve creating only one notifier. Manually fetch the next page when the user reaches a certain scrolling position, and then update the state of the notifier with the old page added to it and the next page that was fetched. I'm not sure how this would be implemented in the new auto-generated Riverpod, but it might be worth exploring.
Most of the times I'm not using a Riverpod's Notifier
for paginated infinite scroll view lists, and this issue is about null
being a problem for the reverse scrollable direction, but nonetheless, thank you for dedicating some time to this.
I just want to underline that this is not a "riverpod issue", but a Flutter one. The fact that using the null
guard comes handy with riverpod is just an implementation detail.
Is there an existing issue for this?
Steps to reproduce
Expected results
since returning
null
initemBuilder
method will be signaling that we reach the end of the list when we scroll down I suppose it should works normally if we returnnull
in the beginning of the list since thebuilder
factory lazily load the items.I'm not sure if that's intended or not.
The use case is I'm trying to implement a fetch on demand behavior, it works well when scrolling down and showing a 'Loading' until I fetch the new data, and I dispose the data that are no longer showing on the screen as I scroll down.
However when try to scroll back up I still apply the same logic (show loading until I get the data) but it throws
'earliestUsefulChild != null': is not true
.Actual results
════════ Exception caught by rendering library ═════════════════════════════════ 'package:flutter/src/rendering/sliver_list.dart': Failed assertion: line 186 pos 16: 'earliestUsefulChild != null': is not true. sliver_list.dart:186 The relevant error-causing widget was ListView main.dart:31 ════════════════════════════════════════════════════════════════════════════════
Code sample
Code sample
```dart import 'package:flutter/material.dart'; void main() { runApp( const MaterialApp(home: MyHomePage()), ); } class MyHomePage extends StatefulWidget { const MyHomePage({super.key}); @override StateScreenshots or Video
Video
https://github.com/flutter/flutter/assets/95232508/947a83ed-b18c-4c44-ad24-aa3f626640d3Logs
No response
Flutter Doctor output
Doctor output
```console Doctor summary (to see all details, run flutter doctor -v): [✓] Flutter (Channel stable, 3.10.1, on macOS 13.2 22D49 darwin-arm64, locale en-EG) [✓] Android toolchain - develop for Android devices (Android SDK version 33.0.2) [✓] Xcode - develop for iOS and macOS (Xcode 14.2) [✓] Chrome - develop for the web [✓] Android Studio [✓] VS Code (version 1.79.2) [✓] Connected device (2 available) [✓] Network resources • No issues found! ```