Skip to content

Commit acd6cad

Browse files
committed
msglist [nfc]: Say we'll show "loading" even when fetch is at other end
This is NFC ultimately because we currently only ever fetch, or show loading indicators, at one end of the message list, namely the start. When we do start supporting a message list in the middle of history, though (zulip#82), and consequently loading newer as well as older messages, my conclusion after thinking it through is that we'll want a "busy fetching" state at one end to mean we show a loading indicator at the other end too, if it still has more to be fetched. This would look weird if the user actually saw both at the same time -- but that shouldn't happen, because if both ends (or even either end) is still open then the original fetch should have found plenty of messages to separate them, many screenfuls' worth. And conversely, if the user does kick off a fetch at one end and then scroll swiftly to the other end and witness how that appears, we want to show them a "loading" sign. The situation is exactly like if they'd had a fetch attempt on that same end and we were backing off from failure: there's no fetch right now, but there won't be one yet, so effectively the loading is busy.
1 parent ef514e5 commit acd6cad

File tree

1 file changed

+13
-8
lines changed

1 file changed

+13
-8
lines changed

lib/widgets/message_list.dart

Lines changed: 13 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -684,16 +684,21 @@ class _MessageListState extends State<MessageList> with PerAccountStoreAwareStat
684684
}
685685

686686
Widget _buildStartCap() {
687-
// These assertions are invariants of [MessageListView].
687+
// If we're done fetching older messages, show that.
688+
// Else if we're busy with fetching, then show a loading indicator.
689+
//
690+
// This applies even if the fetch is over, but failed, and we're still
691+
// in backoff from it; and even if the fetch is/was for the other direction.
692+
// The loading indicator really means "busy, working on it"; and that's the
693+
// right summary even if the fetch is internally queued behind other work.
694+
695+
// (This assertion is an invariant of [MessageListView].)
688696
assert(!(model.fetchingOlder && model.fetchOlderCoolingDown));
689-
final effectiveFetchingOlder =
697+
final busyFetchingMore =
690698
model.fetchingOlder || model.fetchOlderCoolingDown;
691-
assert(!(model.haveOldest && effectiveFetchingOlder));
692-
return switch ((effectiveFetchingOlder, model.haveOldest)) {
693-
(true, _) => const _MessageListLoadingMore(),
694-
(_, true) => const _MessageListHistoryStart(),
695-
(_, _) => const SizedBox.shrink(),
696-
};
699+
return model.haveOldest ? const _MessageListHistoryStart()
700+
: busyFetchingMore ? const _MessageListLoadingMore()
701+
: const SizedBox.shrink();
697702
}
698703

699704
Widget _buildEndCap() {

0 commit comments

Comments
 (0)