Problem
I would like to be able to keep the next item in a list visible when scrolling through a list bigger than the viewable area to make large lists of items more understandable and pleasant to browse through.
Solution
Ideally the item before and after the currently selected item would remain visible while scrolling either up or down.
Or as many items before and after as the api user selects.
We can store a padding value in the ListState struct and have that passed through to the bounds checking that the List performs.
If we add serde(default) to the parameter in ListState we can avoid breaking changes from serialization.
Using this new feature would be the same as existing code for manually setting the offset, so any of the following:
*state.padding_mut() = 1;
state = state.with_padding(1);
state = ListState::default().with_padding(1);
By default padding would be disabled and would have no impact on existing users without any action on their end.
I've developed an existing fork that has this feature working and tested. I've so far been using the name "padding" but I think "scroll_padding" would be much less ambiguous and confusing. I'm open to suggestions.
I've attached gif(s) of current and desired behavior bellow.
Alternatives
Alternatively, I could just handle this myself in the api user side of the code. But it would be very difficult to handle items of inconsistent sizes without reimplementing much of the existing bounds checking code in List rendering.
Additionally doing it that way could leave that user side code vulnerable to otherwise non-breaking changes that adjust how lists are rendered. Like the existing PR for adding what I'd probably describe as list item padding.
Additional context
Current behavior:
Desired behavior:
Problem
I would like to be able to keep the next item in a list visible when scrolling through a list bigger than the viewable area to make large lists of items more understandable and pleasant to browse through.
Solution
Ideally the item before and after the currently selected item would remain visible while scrolling either up or down.
Or as many items before and after as the api user selects.
We can store a padding value in the ListState struct and have that passed through to the bounds checking that the List performs.
If we add serde(default) to the parameter in ListState we can avoid breaking changes from serialization.
Using this new feature would be the same as existing code for manually setting the offset, so any of the following:
By default padding would be disabled and would have no impact on existing users without any action on their end.
I've developed an existing fork that has this feature working and tested. I've so far been using the name "padding" but I think "scroll_padding" would be much less ambiguous and confusing. I'm open to suggestions.
I've attached gif(s) of current and desired behavior bellow.
Alternatives
Alternatively, I could just handle this myself in the api user side of the code. But it would be very difficult to handle items of inconsistent sizes without reimplementing much of the existing bounds checking code in List rendering.
Additionally doing it that way could leave that user side code vulnerable to otherwise non-breaking changes that adjust how lists are rendered. Like the existing PR for adding what I'd probably describe as list item padding.
Additional context
Current behavior:
Desired behavior: