Multiple channel lists with 100+ channel members

[mishkeTz]

There was a new version that introduced support for the new prop channelRenderFilterFn that can be used to add the last step of filtering of channels that should be displayed in the list.

In my case, we have two channel lists that we display on two different screens, and in some cases the group from channel list B would end up in channel list A and vice versa.

Quote from another issue I created #1945

My question for this is because it seems that when there are multiple channel lists i.e. A and B, and when the user sends the message from the channel (list A) then the channel also appears in channel list B, and none of the events handles gets called but the channel just gets added.

---

To fix this issue I used channelRenderFilterFn to add filtering and check if the user is actually a member of that channel or not to have the correct list of channels that are displayed to the user. However, this doesn't work in cases when the group has over 100+ members, because we don't get the full list of members on the channel and the condition check will fail.

channelRenderFilterFn={(channels) => { return channels?.filter(({ state: { members = [] } = {} }) => Object.keys(members)?.includes(userId)); }}

---

The members limit of 100 also makes some other places or features that we want to have on the app difficult...

Is there a way to get the whole list of members or in this case another way to achieve this check?
This all comes to issues when there is an integration of two channel lists in the app...

[vanGalilea]

Might be related to a stale state, we will have a look at it @mishkeTz thanks

[mishkeTz]

Is there any update on this? Will there be a solution to this problem, we are experiencing problems where we have two channel lists with different filters, and due to this issue mentioned above where we have to use channelRenderFilterFn which doesn't work with our condition as we only get 100 channel members back.

@vanGalilea Any updates regarding this on your side? Did you prioritize this topic? Is there a way for me to implement a fix for this on my side?

[vishalnarkhede]

@mishkeTz This is indeed a limitation of chat api at the moment.

Could you tell me more about the product requirements around multiple channel lists? What is channel list A and B? Or what are the filters exactly. Maybe I can suggest some alternative solution.

[mishkeTz]

Hi, sprry for the late response.
Generally the use case is to have channel list rendered on two separate screens with their own list of channels

I.e. there one screen where we want to render only 1on1 channels (channel/chat for two users) and then on another screen we want to render groups to which users can join to.
Now this is making a lot of problems, because it seems that the package is built in a way that it can handle only one instance of the channel rendering screen.

If you have a use-case with two screens and two different lists of channels then the results are mixed and when someone sends a message in one channel it appears in another list of channels.

Screen A:

• render all channels where type is channel_messaging

Screen B:

• render all channels where type is channel_group

[softwarebyze]

Generally the use case is to have channel list rendered on two separate screens with their own list of channels

I.e. there one screen where we want to render only 1on1 channels (channel/chat for two users) and then on another screen we want to render groups to which users can join to.
Now this is making a lot of problems, because it seems that the package is built in a way that it can handle only one instance of the channel rendering screen.

If you have a use-case with two screens and two different lists of channels then the results are mixed and when someone sends a message in one channel it appears in another list of channels.

Screen A:

• render all channels where type is channel_messaging

Screen B:

• render all channels where type is channel_group

I am running into this same exact problem, same use case

[YonahAFeld]

Same issue. @vishalnarkhede @vanGalilea This is causing us to have to redesign our app. Can we get this looked at again?