anchors 1/n: Handle GrowthDirection.reverse in sticky_header #496
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This will help keep down complexity (and depth of indentation) as we make the list view more complex. In particular it will avoid duplication when we start having two back-to-back slivers that both contain message-list items.
This will allow using it as one sliver in a CustomScrollView.
gnprice
added
a-msglist
This is effectively what StickyHeaderListView.builder was abbreviating. This expanded form will then give us flexibility to introduce a second sliver.
This resolves the last of the "TODO dir" comments in this library. We had originally written this library to rely on the assumption that `constraints.growthDirection` was `GrowthDirection.forward`, i.e. that the direction in which `constraints.scrollOffset` increases was the same as `constraints.axisDirection`, in order to keep down the number of distinct directions one needs to keep track of in writing and reading (and debugging) the implementation. But now that this logic is relatively solid within that case -- and now that we have a solid test suite for this library -- we can go back and identify the handful of places that need to be flipped around for `GrowthDirection.reverse`, and do so. This support isn't yet especially *useful*: there are a couple of unrelated bugs which are triggered when the area allotted to this sliver isn't the entire viewport, and there isn't a lot of reason to have a sliver with GrowthDirection.reverse when no other sliver is potentially occupying part of the viewport. We'll fix those separately.
This is a more readable way of expressing the exact same thing.
This means that the overall scroll view has AxisDirection.down as the scroll direction, rather than AxisDirection.up, and the SliverStickyHeader is passed GrowthDirection.reverse instead of GrowthDirection.forward in order to get the same effect. This makes the scrolling a little easier to think about when focused on MessageList's code, because for example (as seen in this diff) `scrollMetrics.extentBefore` now refers to the messages that are older than the ones on screen, rather than those that are newer. This also brings us closer to the setup we'll want for zulip#80 and zulip#82, opening the message list at an anchor other than the end: the empty placeholder sliver at the bottom will become the list of messages after the starting anchor, while the sliver at the top will remain the list of messages above the anchor.
gnprice
force-pushed
the
pr-scroll-reverse
branch
from
fdb8fc2 to
9560245
Compare
|
Thanks! Merged. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the first of several PRs leading us to #80 and #82, opening the message list at an anchor other than the latest message in history.
For this PR, the main work is to lift one of the simplifying assumptions I originally made for an MVP of the
sticky_headerlibrary, allowing the SliverStickyHeaderList to be a sliver that counts backward in the enclosing ScrollView rather than forward.We also rearrange some things in how MessageList builds the list, in order to exercise that new flexibility and to get closer to how we'll want things when implementing #80 and #82.
Main commit messages
sticky_header: Handle GrowthDirection.reverse
This resolves the last of the "TODO dir" comments in this library.
We had originally written this library to rely on the assumption
that
constraints.growthDirectionwasGrowthDirection.forward,i.e. that the direction in which
constraints.scrollOffsetincreaseswas the same as
constraints.axisDirection, in order to keep downthe number of distinct directions one needs to keep track of in
writing and reading (and debugging) the implementation.
But now that this logic is relatively solid within that case --
and now that we have a solid test suite for this library -- we can
go back and identify the handful of places that need to be flipped
around for
GrowthDirection.reverse, and do so.This support isn't yet especially useful: there are a couple of
unrelated bugs which are triggered when the area allotted to this
sliver isn't the entire viewport, and there isn't a lot of reason
to have a sliver with GrowthDirection.reverse when no other sliver
is potentially occupying part of the viewport. We'll fix those
separately.
msglist [nfc]: Let ScrollView count forward, and sliver handle reverse
This means that the overall scroll view has AxisDirection.down
as the scroll direction, rather than AxisDirection.up, and the
SliverStickyHeader is passed GrowthDirection.reverse instead
of GrowthDirection.forward in order to get the same effect.
This makes the scrolling a little easier to think about when focused
on MessageList's code, because for example (as seen in this diff)
scrollMetrics.extentBeforenow refers to the messages that areolder than the ones on screen, rather than those that are newer.
This also brings us closer to the setup we'll want for #80 and #82,
opening the message list at an anchor other than the end: the empty
placeholder sliver at the bottom will become the list of messages
after the starting anchor, while the sliver at the top will remain
the list of messages above the anchor.