widget.List with variable-sized canvas objects

[hkparker]

I'm developing a chat app, where I anticipate some threads will have tens of thousands (or more) of messages. These messages are displayed via a custom chatBubble widget, which has a flexible size depending on the length of the message and size of the app.

I'm currently putting these message threads in container.Scrolls. So far with a small number of test messages there's no problem, but I understand that this is not very efficient and I'll probably run into performance problems with real data, and that widget.List would be better for such a large amount of widgets.

However, per the documentation:

List requires that all items are the same size.

What are my options here? Is there a path to supporting variable sized canvas objects in a widget.List? I'm having a hard time coming up with schemes that will allow me to reduce the overhead inside a scroll.

[andydotxyz]

We recently added List.SetItemHeight which is probably what you are looking for.

[hkparker]

Thanks, that does appear to do what I need, however I still have a few things to figure out. Also here's a quick PR for removing that line in the documentation, if you'd like to make that change.

It looks like list items are indexed based on ListItemID which is just an ordered integer that indicates where in the list an item is, like a slice index as seem in the example. So, setting the height of item 5, for example, means that the 5th item in the list is resized. If another item were to be appended to the beginning of the list, then item 5 would become item 6, and both 5 and 6 would need to be resized. I'm assuming here that it's ok to mutate any part of the underlying data structure the list is using and just refresh the list after, but please correct me if I'm wrong.

This is fine for my uses I think, all of the items I want to put into a list have a UUID, so I'd have to have some sort of additional data structure to track which ListItemID corresponds to which UUID, and update them as things are added / deleted, but that's doable. It seems to me that using a list would still be more efficient as long as I'm just appending things and then setting their height, but if I were to add something to or delete something from the beginning of a list I'd have to reset the height of every item, and I'd end up refreshing everything, and that would be as expensive as a scroll. This is still an improvement of course since most of the time I'll just be appending. Since these are chat messages with a "disappearing messages" feature, I'll occasionally be deleting a message from the top of the list, and shifting the ListItemIDs for everything, causing me to have to reset the height of all items in the list.

[hkparker]

Oh scrolling is essential, the context here is a chat history with possibly tens of thousands of messages, I merely meant the visual indicator bar on the side of the scroll showing your positions. Some apps, like Slack, don't have that (at least on mobile) so it's a UX thing I'll probably want to try out.

[andydotxyz]

Weird, slack shows a scrollbar for me.
If you want to disable selection and hover you can extend the List widget and just swallow those events.

[hkparker]

Re: slack, might be an android / iOS thing. And yep that's the plan, I won't be getting to this immediately but if I come across any cool tricks for the height I'll share what I find.

[dweymouth]

Just to follow up and clarify - the way to disable selection on List is to have your list rows swallow (and do nothing with) Hover and Tap events.. and ALSO extend the List itself to imiplement Disableable and hard-code it to always be disabled. This blocks the keyboard focus way to select items which can't be blocked just with the row widgets.

[hkparker]

Thanks for the clarification. Hard to say exactly what I'll want to do here until I get into it since I'll want the messages to be clickable for some feature down the road (like adding emoji reactions and seeing additional details). I might even want there to be some sort of multi-select thing eventually, but until I build all of that it'll be preferred to not have selection UI behaviors.