fix: performance improvement for message list render item

[khushal87]

The PR focuses into optimising the behaviour of our MessageList/MessageFlashList. As a result of it move renderItem completely out of the MessageList and MessageFlashList. The changes mostly are as follows:

• Create a separate state store for channel unread state and use the state where it's intended to be used and not unnecessarily drilling it down.
• Create a store for message list where each message id would store its prev and next message - this is later used to calculate the date separator and group styles for the message at the level of the message (should be much better can calculating on top as this avoids repetitive calculations as we had before). We were iterating over the entire list multiple times inside the getGroupStyles and getDateSeparators to do the same job.
• As a result, renderItem just was dependent on stable props so I decided to create a context MessageListItemContext for the same and use it inside MessageWrapper component thereby moving the renderItem out of the MessageList which was always our goal.

This obviously came with a couple of deprecations which we cannot remove right now but may be in the future which will make the code cleaner and faster as we get rid of the unnecessary calculations we still need to have within the code.

[Stream-SDK-Bot]

SDK Size

title	develop	branch	diff	status
js_bundle_size	302 KB	304 KB	+2435 B	🔴

[isekovanic]

This looks like the right direction from what we talked about, at least as an initial first pass !

Let's please make sure that:

• New messages do not cause renderItem to change (i.e in the profiler "reason for change" suspects, should be the case as all dependencies of it now look stable)
• New messages do not cause heavy downstream rerenders (I believe you already got this to some point from what we spoke last time)

Also, please benchmark with read events enabled (otherwise this won't make any difference).

[khushal87]

This looks like the right direction from what we talked about, at least as an initial first pass !

Let's please make sure that:

• New messages do not cause renderItem to change (i.e in the profiler "reason for change" suspects, should be the case as all dependencies of it now look stable)
• New messages do not cause heavy downstream rerenders (I believe you already got this to some point from what we spoke last time)

Also, please benchmark with read events enabled (otherwise this won't make any difference).

So,

New messages do not cause renderItem to change (i.e in the profiler "reason for change" suspects, should be the case as all dependencies of it now look stable)

I did test it on profiler and doesn't look bad for now.

New messages do not cause heavy downstream rerenders (I believe you already got this to some point from what we spoke last time)

Yeah number of re-renders are significantly less compared to develop branch

benchmark with read events enabled (otherwise this won't make any difference)

I enabled the events on our benchmark app and tested but didn't see anything worse.

NOTE: I will request you to run the change as well so that if I am missing out on something around performance degradation, you can point me out.