MessageList long loading logs

[chrisbobbe]

To help debugging #4156; see also discussion around https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/.23M4156.20Message.20List.20placeholders/near/921700, where we'll have the debugging conversations.

[gnprice]

Thanks @chrisbobbe !

I'm about to merge this, in the interest of getting out a beta today that will help debug #4156. As you say in the last commit message, though, it'd be good to structure that logging code a bit better. A few thoughts:

• The log-long-load state and all the logic referring to that state could be encapsulated in a class, with an instance created at toplevel (where the setTimeout(maybeLogLongLoad, …) is now.)
• The logic added to handleMessageEvent could then be one line just invoking a method on that instance, just passing uevent.
• The map callback that produces loggableEvents could be pulled out and given a name like scrubUpdateEvent -- then logLongLoad would be much shorter.
• In that map callback, I think it's more robust (even though it's a bit more boilerplate) to have each case name all the properties it's passing through, rather than say ...rest. In particular this means that if we add a new property to one of these, it doesn't get logged until we explicitly consider how to handle it.
  • A related illustration, perhaps: in the typing case I think the placeholdersDivTagFromContent will always just return null, because the typing content is focused on just the typing-status elements. Probably the boolean content !== '' is as much information from that as could be useful, but also there wouldn't be much lost by just omitting it entirely.

[chrisbobbe]

Cool, thanks for those suggestions!