Add option for different ScrollPosition behavior on keyboard appearance #2112
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.
Hello 👋
Context
The default
tableView.scrollTo
with aScrollPosition.none
should animate in a way that the cell is fully visible. It works in most cases, but it seems to fail (scrolls out of view bounds) in the case of a cell preceding a very long footer. Most of the blame here is on Apple side, as I'll show below, however this change request could easily allow to bypass the issue.Example/Experiment
In this commit (lcoderre@13c5d65) I modified the examples to add a very long Lorem Ipsum footer to a section, and also demonstrated using a pure UITableViewController with scrolling on every cell-click.
👀 - You might notice I recorded this on
iPhone 11 pro
simulator, but I also repeated the test on iPhone 8, 6s. Same Same.👀 - Even a pure UITableViewController scrolls out of view for that last cell. And on the Eureka's Native Event UI, it acts a bit differently, but buggy all the same. It is worth noting that Eureka's scrolling behavior shown in the following gif isn't exactly the same as we're observing in our app using Eureka. In our case, it's more like Apple's version 🤷♂️ To be honest, I haven't dug in detail to find the reason.
See scrolling using
.none
See now using
.top
(👀 no bug)Proposed solution
The proposed solution has the advantage of being "additive" and not "disruptive". I.e. it won't break anyone's code, but will allow some of us to bypass a nasty problem :)