Autocomplete for topic to send to

[gnprice]

We should offer autocompletion in the topic input of the compose box. (When that topic input exists, i.e. for interleaved narrows.)

This is a step on the way to:

• Review UX of compose box in interleaved narrows #149

and an element we'll almost surely want in any UX solution we choose there.

Not to be confused with autocomplete for mentioning a topic inside the content of a message:

• stream/topic autocomplete (e.g. #**mobile**) #124

[Khader-1]

I've reviewed this task, and I believe it's one step up compared to my previous contributions. I am confident I can tackle it effectively.
To address this, I propose the following steps:

• Implementing a new API call to retrieve data from https://chat.zulip.org/api/users/me/:stream_id/topics
• Modifying the widget structure to incorporate autocomplete functionality, similar to the message compose input
• Developing a view model and a controller similar to those used for the compose input

I am keen to take on this task and intend to start by creating an initial prototype before requesting formal assignment.

[gnprice]

@Khader-1 Sounds good! Please go ahead.

[timabbott]

This data structure is likely a thing that will end up being used for other things. stream_topic_history.ts in the Zulip web app may be a useful reference. There are some messy/subtle problems with how it tries to live-update, detailed in zulip/zulip#29015, so a lot of the current complexity is wrong. But specifically the logic in stream_topic_history_util.ts might be a helpful reference for how the web app does fetch-on-demand these data, and caches it.

(It can take like 0.5s to get a response in a stream with thousands of topics).

[gnprice]

Thanks Tim!

For a solution for this issue, I think I'd be happy with a version where the list of topics for a given stream is only cached for the lifetime of a given autocomplete interaction — that is, for the lifetime of a given topic input field.

In particular that avoids most of the complexity of maintaining the data structure, because it's OK if it doesn't stay accurately in sync in subtle edge cases (and really it's 95% OK if it doesn't get updated at all), because not many changes will happen during its lifetime.

The main cost is that 0.5s lag to get the list of topics. But we'd have that anyway the first time a user goes to compose in a given stream, so I'm not sure there's a huge difference between that and every time.

Hmm, though I guess one benefit of keeping it around longer is that we could be more eager about fetching it — like when you view a given stream narrow, rather than when you start composing. Then you might rarely actually see the 0.5s latency.

---

In any case: for when we do tackle this data structure (as part of this issue or later), see also RecentDmConversationsView. That's our efficient data structure for maintaining the list of your recent DM conversations; I think one wants basically the same data structure for that as for topics in a stream. (The event handling will be a bit different, though, and the event handling we have already for DMs is likely incomplete anyway.)

So I'd want to factor that out into a somewhat more generic list-of-recent-conversations data structure, with RecentDmConversationsView as a wrapper around that, and then add the recent-topics-per-stream data structure as another such wrapper.