Allow viewing message edit history

[chrisbobbe]

@timabbott said:

I think this is a checkbox feature, where there's a lot of value in it, even if the polish isn't great. (FWIW, the Zulip webapp's display of topic edits is semi-broken and has been since it was first implemented, for example)

See more discussion around that quoted message.

---

The endpoint it looks like we'll want to use is documented here.

We have a binding for it, in src/api/messages/getMessageHistory.js, that currently isn't used.

Conveniently, just as with messages themselves, it looks like the diff we want to display, content_html_diff, is HTML, which we can render in a WebView.

I think a major question we'll need to answer first is whether the edit history should be viewed in the same WebView used to display the message list, or if it should be a new WebView.

There's been some discussion around here of introducing a new WebView for the particular reason that we want to replicate a complicated (but useful) bit of the web app's UI so we don't have to reinvent it ourselves: in that case, the settings UI (which indeed has a lot of stuff going on).

Here, though:

• The stuff we want to display isn't particularly various or complicated: a list of edit items, where each edit item shows the diff, the timestamp, and the person who made the edit (I'm guessing there's an admin feature to allow non-authors to edit messages).

• Also, Tim says this about the web app's implementation:

  @timabbott said:

  the webapp's implementation of it is one of our least polished features, but people clearly do like it despite that.

Given these observations, I'm currently inclined against dropping the web app's implementation into its own WebView (with the tweaks necessary to make that possible), even though it might be a win for developing our code-sharing infrastructure.

In this train of thought, if we do put it in its own WebView (separating it from the MessageList), then we should do so for different reasons. Possibly, just wanting to avoid complicating the existing WebView is sufficient. I'm leaning that way, currently; presumably, we'd be responding to a long-press, or something in the action sheet, and the bulk of the logic for those handlers is already outside the message list's WebView. But I could anticipate hesitation about a multiplicity of WebViews.

@gnprice, thoughts?

[gnprice]

if we do put it in its own WebView (separating it from the MessageList), then we should do so for different reasons. Possibly, just wanting to avoid complicating the existing WebView is sufficient. I'm leaning that way, currently; presumably, we'd be responding to a long-press, or something in the action sheet, and the bulk of the logic for those handlers is already already outside the message list's WebView.

That sounds like a good reason to me.

This will be a lot like MessageReactionList -- it's an additional screen in the navigation, which you get to from long-press to see more details about a specific message. That seems a lot simpler to implement and maintain than adding to the existing WebView, and on a phone's (small) display it's probably a nicer UX anyway.