Add ultra basic support for the SubMessage-based polls feature

[timabbott]

Zulip has an experimental "polls" feature, which uses the special SubMessage table in the database for its storage (https://zulip.readthedocs.io/en/latest/subsystems/widgets.html#poll-todo-lists-and-games). You can create one on web by sending a message with /poll as the content. The UI is currently pretty janky; we have a separate issue on web (zulip/zulip#11010) for improving that.

The polls feature has been getting a decent amount of interest from folks who want it in Zulip Cloud, so we need to take steps to make them display in a not-totally broken fashion on mobile.

Structurally, the widgets / submessage feature has some important properties for mobile: The API only sends and receives JSON, via submessage events (or the .submessage field on a message object fetched from the server). The client is completely responsible (and empowered) to render the data as it pleases, as well as enabling UI.

In terms of staging, I think there's a few levels of mobile-side support for this widget (or any other widget for that matter, though the others are more prototypes and don't have a lot of demand so we shouldn't worry about them).

• First, mobile can literally look for messages with a poll submessage/widget entry as the most immediate hack to detect and say "This message is a poll, which is not supported on mobile yet.".
• From there, it can process the data from those events properly, and do a basically textual rendering of the poll results, so you can at least understand the message.
• And then from there we could work on rendering the results and turning on UI to actually participate in the poll from your device.

[borisyankov]

@timabbott To clarify some aspects that seem to be true:

• we can differentiate between normal messages and widgets by submessages.length > 0 ?
• msg_type of a submessage can be only widget currently?
• submessages can only be added to, no update/delete?
• content is always intended to be JSON string?

[timabbott]

we can differentiate between normal messages and widgets by submessages.length > 0 ?

yes.

msg_type of a submessage can be only widget currently?

yes; the client can ignore any other submessage until if/when we change that.

submessages can only be added to, no update/delete?

currently, yes, though that could change in the future.

content is always intended to be JSON string?

yes.

[timabbott]

@borisyankov @gnprice how close are we to merging this? We've been getting complaints from users about the frankly poor situation that polls are invisible in the mobile apps.

[borisyankov]

@timabbott we have the #3220 ready to merge.
It does support the processing, understanding and storage of submessages.

It visualizes a placeholder that says we do not support 'widgets' yet though.
That is better than just missing the message but not by much.

I have started the next phase in a PR that is very WIP and far from done.

To clarify where I think the effort in implementing it fully lies:

• recognizing and processing the general submessage data - 25% (done)
• recognizing and visualizing all widgets - 50% (10-20% done)
• interacting with the widgets - 25%

When talking with Rishi about the widgets (not directly this PR) he said we consider it less of a priority, maybe compared to the effort to implement. Thus I have been a bit unclear if we should push on this or other issues.

[timabbott]

I chatted with Rishi about this. I think this is a P1 issue, specifically for just the /poll widget. There's hardly any other widgets today and no other widgets are likely to be important in the next 6+ months, and new widgets we add may involve adding new APIs for them. So while we generally aim to build things generally, hacking together a solution that covers /poll by e.g. copying some code from the webapp is totally reasonable for this feature.

So we should prioritize improvements beyond "/poll isn't supported on mobile" (maybe with a link to open that page in the webapp) to the extent that finishing the rest of /poll is easier than finishing out other P1 issues (of which I feel like we have a ton with an open PR).

[gnprice]

Small update: I just merged #3220 , so we'll now show

• the /poll Where shall we go for lunch? line
• and also a big grayed-out box saying "Interactive message -- To use, open on web or desktop".

(The main part of this issue remains open.)