You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a follow-up to #83: when looking at the message list, the messages on the screen can suddenly jump when certain changes happen.
The cases of a new message in a message event, or messages newly fetched on scroll, were covered by #1507; new messages now appear in the downward-growing bottom sliver instead of the upward-growing top sliver (which had been effectively the only sliver until recently). In the #1507 description these were called cases (a) and (b).
This issue is that the messages on the screen can still jump when any of a variety of less-common events occur. As described in #1507, those are: (c) deleting messages, or moving them away, when they're not the very oldest or latest; (d) moving messages into the middle of the list; (e) likely on some cases of editing messages so that their height changes; (f) similarly on a message going from no reactions to some reactions or back, or other changes that affect its displayed height.
Implementation
For (c) and (d), I think the Flutter API has the hooks we'd need (we'd make our own implementation of RenderSliverBoxChildManager), but fundamentally it's a subtle problem; in particular we'd need a richer data structure for the list of messages than a List or Queue.
For (e) and (f), and for that matter as a possible alternative solution for (c) and (d) or even (a) and (b), I believe we could use a ScrollController. When something changes, we'd calculate what the right scroll position is in the new state of things, and call jumpTo to go there. Or perhaps we'd override ScrollController.createScrollPosition? The example of PageController, mentioned in that doc, sounds potentially promising as a model.
Specifically we have at this point our own ScrollController and ScrollPosition subclasses, namely MessageListScrollController and MessageListScrollPosition, which were introduced in the PRs leading up to #1507 in order to handle some related needs. So this latter solution would mean making further changes there.
The text was updated successfully, but these errors were encountered:
This is a follow-up to #83: when looking at the message list, the messages on the screen can suddenly jump when certain changes happen.
The cases of a new message in a
message
event, or messages newly fetched on scroll, were covered by #1507; new messages now appear in the downward-growing bottom sliver instead of the upward-growing top sliver (which had been effectively the only sliver until recently). In the #1507 description these were called cases (a) and (b).This issue is that the messages on the screen can still jump when any of a variety of less-common events occur. As described in #1507, those are: (c) deleting messages, or moving them away, when they're not the very oldest or latest; (d) moving messages into the middle of the list; (e) likely on some cases of editing messages so that their height changes; (f) similarly on a message going from no reactions to some reactions or back, or other changes that affect its displayed height.
Implementation
For (c) and (d), I think the Flutter API has the hooks we'd need (we'd make our own implementation of
RenderSliverBoxChildManager
), but fundamentally it's a subtle problem; in particular we'd need a richer data structure for the list of messages than aList
orQueue
.For (e) and (f), and for that matter as a possible alternative solution for (c) and (d) or even (a) and (b), I believe we could use a ScrollController. When something changes, we'd calculate what the right scroll position is in the new state of things, and call
jumpTo
to go there. Or perhaps we'd overrideScrollController.createScrollPosition
? The example ofPageController
, mentioned in that doc, sounds potentially promising as a model.Specifically we have at this point our own ScrollController and ScrollPosition subclasses, namely MessageListScrollController and MessageListScrollPosition, which were introduced in the PRs leading up to #1507 in order to handle some related needs. So this latter solution would mean making further changes there.
The text was updated successfully, but these errors were encountered: