It is possible to obtain users without creating the first room

[andersonqi]

I can't get the available users to create a room, If I haven't created a room by default before.

Is it mandatory to create a room and then get the available users?

[xxRockOnxx]

i actually would love this.

In my case because the code is implementing a Typescript interface, it should all return first conversations (including recipients/users) before filling it up with messages.

Problem is upon subscribing, messages comes right away when the Conversation hasn't been returned yet from the method to be stored in a Map somewhere else.

My workaround is to just:

• subscribe just to get users/recipients (without calling callback handler)
• create a Conversation
• subscribe again to receive messages but this time it will call the callback handler (it will cancel the old subscription)

[minaorangina]

Hi, you are able to get users in our server SDKs. If you feel this behaviour is needed in the client SDK, we'd be curious to understand the use case, and perhaps we can add it to our backlog.

Here's a link to how you can achieve this server side: https://pusher.com/docs/chatkit/reference/server-node#get-users

[minaorangina]

Duplicate of #207

[neuropass]

yeah this is a bug really... please re-open. you should be able to get the list of the users without subscribing to a room. here the use case:

-In order to display you unread messages counts and online status for example, I need to join the room with that user. Unfortunately, this is a big limitation of Chatkit... - it doesn't provide those 2 information without joining the room. That way I cannot "push" unread conversations to the top as well as online users.

The problem with this is that getting a list of thousands of users it slows down to a CRAWL!
For example we need to have filters in place to gather a list of users priority like this:

-users that are online first
-alphabetical order
-lazy load in batches (ideally on scroll so we don't trigger some weird pusher too many request error)

so we have a massive problem here. Things get super slow when you have a little as 500 users to deal with. The status of the user cannot be filter correctly.