Show a list of active channels

[megamattron]

Or figure out some way for users to discover other channels that they can chat in.

[megamattron]

One simple way we could do this is add support for linking to channels, i.e. #breakerapp, and then have the bot post a message every once and a while with the top active channels. Then we wouldn't need new UI at least.

[KenavR]

I have some ideas for this and will write up a couple of proposals. I hope I will get to it tonight.

[KenavR]

For now I have two suggestions.

1. Most active rooms

Load the most active rooms, which are the ones with the most messages in the past month or with the most online users.

Implementation steps

Server

• Add route for most active channels

Client

• Load most active channels
• Add to store
• Add component (like the suggestion below)

2. Recommendations based on the users subreddit subscriptions

Load the users subscriptions sort out the ones the user has already open and maybe sort by popularity based on data from the server (most active channels)

Implementation steps

Server

• Sort result of subscribed channels
• or nothing and just display random 5 ones

Client

• Load subscribed channels from reddit
• Add to store
• Add component

How it could look like

If you like it, I could prepare a pull request, after I get the project working.

[rickhanlonii]

Great stuff @KenavR, love the design.

A minor note: the outline you have for the steps would work for sure, but on page load we would need to have some sort of loading indicator. That would be unique in the app because we're currently sending the entire state object with the page so that the page loads instantly on load.

So I think the steps for this would be:

Sever:

• Add active channels to state
• Add subscribed subreddits to state

Client:

• Update sidebar component to handle new data

[KenavR]

Thanks for the feedback.

I started implementing active channels since I don't need any data from the Reddit api for that. Regarding the subscribed channels, do you think it is the best way to include them into the initial response? They are not really vital information at the start of the app but introduce an additional request for the server. I can't estimate if the request makes the initial response significantly slower (guess not), but I also have some additional suggestions for displaying data from the Reddit api, which would include additional requests.

If you don't like the loading indicator I could hide the entire list until the client has all data needed, but I think as the site grows loading everything at application start won't be performant (is this a word in English? Chrome and some dictionaries say no, others say yes). Also if you don't want a loading indicator, what's your suggestion for the "more" button? I thought of showing a small loading animation and adding new entries to the list. My alternativ solution would open a new page with the "entire" list, which at some point could also be a pretty huge list - there are 200,000+ subreddits.

If you already discussed that in the past and want it in the initial state, I will implement it that way.

[megamattron]

re: including the subscribed channels in the initial state: I kind of get those "for free" since I need to go find out what channels the user is subscribed to in order to get the initial messages. So for the moment it's fine. All of this will start breaking down once people subscribe to hundreds of channels, but we can deal with that when we get there.

As for the active channel list, I suggest caching it and recalculating every X mins. So it can be included in the initial state too.

I'm happy to help with the server side of the active list if we can decide what the definition of active is that we want - can be something simple like people online right now to start I guess.

[KenavR]

When you talk about subscriptions do you mean rooms opened in Breaker or subscribed subreddits? For suggestions based on the users interest we need the later, but if they are already read on the server that's great.

For the active channels I current use the following SQL query (I missed some properties that are required for displaying it properly - maybe I will drop the handwritten query in favor of ORM and add the count manually)

        sb.append("SELECT cr.displayname AS roomName, COUNT(DISTINCT user_id) AS activeUsers FROM chatroom cr ");
        sb.append("LEFT JOIN message m on cr.id = m.room_id ");
        sb.append("WHERE m.createdate > (current_timestamp - interval '30 days') ");
        sb.append("GROUP BY cr.displayname ");
        sb.append("ORDER BY activeUsers desc ");
        sb.append("LIMIT :limit ");
        sb.append("OFFSET :offset");

= Number of users that wrote something in the last month. I guess I will change the '30 days' into a parameter, but the server stuff for the initial response is finished, I just need to add the front end code and an endpoint to load additional rooms. Sadly the next day I will have little to no time to finish the PR.

[megamattron]

That query looks pretty good, but we might want to change over to something more like "people who you can chat with right now." A room that was busy two weeks ago but hasn't seen action since isn't as useful as a room that has 2 people in it right now, even if the message volume is much lower. Does that make sense? I'm happy to try this query first though too and just change if we need to.

I think we can skip the recommended rooms right now since we don't have enough active rooms to make up a list of active, and a list of other recommended rooms. i.e. The only rooms worth recommending will be the set of active rooms :)

[KenavR]

I guess you were right, already got a request for a more current list. The possibility to change the time span (today, week, month) for creating the list came up. I will look into it.

[rickhanlonii]

@megamattron @KenavR what's the status here? Looks like we have active rooms, should we close this an open a new issue if we want other enhancements?