fix: performance improvement for message list render item #3306

khushal87 · 2025-11-28T15:47:32Z

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.

…ve into develop

Stream-SDK-Bot · 2025-11-28T15:57:39Z

SDK Size

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

…ve into perf/message-list-render-item

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).

package/src/components/MessageList/MessageFlashList.tsx

isekovanic · 2025-12-09T10:54:43Z

package/src/components/MessageList/MessageList.tsx

-      setIsUnreadNotificationOpen(false);
-      return;
-    }
+    const lastReadMessageId = channelUnreadState?.last_read_message_id;


Since we already have the state store here, why not just use it here and do something like channelUnreadStateStore.getLatestValue()?.last_read_message_id ?

We're anyway only interested in it if the sticky header needs to be updated and we'll have one less dependency to worry about later on if/when we decide to remove the stable callbacks (i.e with advanced react compiler compatibility).

I need to check. I am worried if this change you asked for will account for updated state as we won't rely on selector but since its an imperative call to the method it should get the updated value so it should technically work.

How so ? The store always has a stable reference and you need to check it only in certain scenarios. If anything, relying on channelUnreadState breaks the references as it will change quite often. This just makes sure we only fetch it whenever we need it.

I have modified it to get the data when from the store and not rely on selector anymore. We can do it as we don't directly depend on the data anyways here and we will have updated values when the function or the below useEffect is called so gtg.

isekovanic · 2025-12-09T10:56:53Z

package/src/components/MessageList/MessageList.tsx

      const lastItemCreatedAt = lastItemMessage.created_at;

-      const unreadIndicatorDate = channelUnreadState?.last_read.getTime();
+      const unreadIndicatorDate = channelUnreadState?.last_read?.getTime();


Same deal here pretty much

isekovanic · 2025-12-09T10:58:41Z

package/src/components/MessageList/MessageList.tsx

-                : new Date(0)), // not having information about the last read message means the whole channel is unread,
-            unread_messages: previousUnreadCount + 1,
-          };
+        const previousUnreadCount = channelUnreadState.unread_messages ?? 0;


Same here, the (stable) state store would be the only dependency and we can "peek" into the unread state on the fly, whenever we need it (i.e whenever a new event arrives). As it currently is, the useEffect will be rerun every time this changes, which we want to avoid.

package/src/components/MessageList/MessageList.tsx

isekovanic · 2025-12-09T11:07:07Z

package/src/components/MessageList/hooks/useMessageList.ts

  const { threadMessages } = useThreadContext();
  const messageList = threadList ? threadMessages : messages;

+  const filteredMessageList = useMemo(() => {


What is the purpose of having another memoized list value here ? It's an overhead of something that'll be considered a "hot path" if it serves no particular purpose. Unless we have a very good reason to have it here, please move it back to the useMemo below.

So, the same filtering was done at 2 places getGroupStyles and getDateSeparators. So, I decided to filter it once and share the filtered message list as my source to calculate the logic for date and group styles. This is an optimization for large messages as previously this would just run over and over as we paginate but now the loop will just run once. Better computation in general.

My question is, why not just do it further down where everything else is handled ? We don't need to keep 2 instances of the same list in memory. It's arguably worse to do that

We have the list of messages here so its filtered out of it. What do you mean by it can be done further down? I didn't get it. Besides this is the one used to get the prev and next message in the state store so I am unsure where else it could have been handled.

Also, its just the matter of time until we remove it and then you would see its real advantage as the calculations would be limited to one.

package/src/components/MessageList/utils/getDateSeparators.ts

package/src/components/MessageList/utils/getLastReceivedMessage.ts

package/src/components/MessageList/hooks/useMessageList.ts

isekovanic · 2025-12-09T11:15:57Z

package/src/components/MessageList/hooks/useMessageDateSeparator.ts

+}) => {
+  const selector = useCallback(
+    (state: MessagePreviousAndNextMessageStoreType) => ({
+      previousMessage: message ? state.messageList[message.id]?.previousMessage : undefined,


As a note, please triple check that the references towards previousMessage and nextMessage are kept stable (as much as they can be at least).

Otherwise, this selector will fire everywhere, on every new message and it's all for nothing. The only time they won't be stable is during optimistic updates of messages, where (at least) the created_at date will change.

I don't think this should happen as per how message-list-prev-next-state.ts is designed but I am open to look into it if you think things would change often. I take care of the reference and skip it in that case.

Yes, please confirm that the references do not change here.

In my opinion it shouldn't the way its written atm but I am open for discussion if you think it would and improve it.

package/src/components/MessageList/hooks/useMessageList.ts

…ve into perf/message-list-render-item

khushal87 · 2025-12-11T05:44:45Z

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.

khushal87 added 3 commits November 27, 2025 22:54

Merge branch 'develop' of github.com:GetStream/stream-chat-react-nati…

7f0fe8a

…ve into develop

fix: performance improvement for message list render item

7ce0e69

fix: performance improvement for message list render item

2300afc

khushal87 added 5 commits December 4, 2025 14:17

fix: date separator and group styles extraction to store

70ed772

fix: date separator and group styles extraction to store

fc3a839

Merge branch 'develop' of github.com:GetStream/stream-chat-react-nati…

bdb763a

…ve into perf/message-list-render-item

test: update snapshots

9f7638e

Merge branch 'develop' of github.com:GetStream/stream-chat-react-nati…

fc728a3

…ve into perf/message-list-render-item

khushal87 marked this pull request as ready for review December 4, 2025 16:06

khushal87 requested review from isekovanic and oliverlaz December 4, 2025 16:06

khushal87 added 2 commits December 5, 2025 13:15

fix: remove redundant prop from useMessageGroupStyles

bd6b659

fix: isNewest prop rerender

5248e2b

isekovanic requested changes Dec 9, 2025

View reviewed changes

isekovanic reviewed Dec 9, 2025

View reviewed changes

package/src/components/MessageList/hooks/useMessageList.ts Outdated Show resolved Hide resolved

khushal87 added 6 commits December 9, 2025 18:43

fix: optimize the message list prev and next state

e1f3e4c

fix: optimize the message list prev and next state

cc6ab46

fix: optimize the message list store usage

6b7715e

Merge branch 'develop' of github.com:GetStream/stream-chat-react-nati…

653d4ef

…ve into perf/message-list-render-item

fix: optimize MessageWrapper

023d1b2

fix: usage of state store in list

0e05faa

fix: performance improvement for message list render item #3306

Are you sure you want to change the base?

fix: performance improvement for message list render item #3306

Uh oh!

Conversation

khushal87 commented Nov 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Stream-SDK-Bot commented Nov 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

SDK Size

Uh oh!

isekovanic left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

khushal87 commented Dec 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

khushal87 commented Nov 28, 2025 •

edited

Loading

Stream-SDK-Bot commented Nov 28, 2025 •

edited

Loading

khushal87 commented Dec 11, 2025 •

edited

Loading