Matterhorn.State.Messages

Documentation

data PostToAdd

When we add posts to the application state, we either get them from the server during scrollback fetches (here called OldPost) or we get them from websocket events when they are posted in real time (here called RecentPost).

Constructors

OldPost Post

A post from the server's history

RecentPost Post Bool

A message posted to the channel since the user connected, along with a flag indicating whether the post triggered any of the user's mentions. We need an extra flag because the server determines whether the post has any mentions, and that data is only available in websocket events (and then provided to this constructor).

lastMsg :: RetrogradeMessages -> Maybe Message

sendMessage :: ChannelId -> EditMode -> Text -> [AttachmentData] -> MH ()

Send a message and attachments to the specified channel.

editMessage :: Post -> MH ()

deleteMessage :: Post -> MH ()

addNewPostedMessage :: PostToAdd -> MH ()

addObtainedMessages :: ChannelId -> Int -> Bool -> Posts -> MH PostProcessMessageAdd

Adds the set of Posts to the indicated channel. The Posts must all be for the specified Channel. The reqCnt argument indicates how many posts were requested, which will determine whether a gap message is added to either end of the posts list or not.

The addTrailingGap is only True when fetching the very latest messages for the channel, and will suppress the generation of a Gap message following the added block of messages.

asyncFetchMoreMessages :: MH ()

Fetches additional message history for the current channel. This is generally called when in ChannelScroll mode, in which state the output is cached and seen via a scrolling viewport; new messages received in this mode are not normally shown, but this explicit user-driven fetch should be displayed, so this also invalidates the cache.

This function assumes it is being called to add "older" messages to the message history (i.e. near the beginning of the known messages). It will normally try to overlap the fetch with the known existing messages so that when the fetch results are processed (which should be a contiguous set of messages as provided by the server) there will be an overlap with existing messages; if there is no overlap, then a special "gap" must be inserted in the area between the existing messages and the newly fetched messages to indicate that this client does not know if there are missing messages there or not.

In order to achieve an overlap, this code attempts to get the second oldest messages as the message ID to pass to the server as the "older than" marker (postQueryBefore), so that the oldest message here overlaps with the fetched results to ensure no gap needs to be inserted. However, there may already be a gap between the oldest and second-oldest messages, so this code must actually search for the first set of two *contiguous* messages it is aware of to avoid adding additional gaps. (It's OK if gaps are added, but the user must explicitly request a check for messages in order to eliminate them, so it's better to avoid adding them in the first place). This code is nearly always used to extend the older history of a channel that information has already been retrieved from, so it's almost certain that there are at least two contiguous messages to use as a starting point, but exceptions are new channels and empty channels.

asyncFetchMessagesForGap :: ChannelId -> Message -> MH ()

asyncFetchMessagesSurrounding :: ChannelId -> PostId -> MH ()

Given a particular message ID, this fetches n messages before and after immediately before and after the specified message in order to establish some context for that message. This is frequently used as a background operation when looking at search or flag results so that jumping to message select mode for one of those messages will show a bit of context (and it also prevents showing gap messages for adjacent targets).

The result will be adding at most 2n messages to the channel, with the input post ID being somewhere in the middle of the added messages.

Note that this fetch will add messages to the channel, but it performs no notifications or updates of new-unread indicators because it is assumed to be used for non-current (previously-seen) messages in background mode.

fetchVisibleIfNeeded :: TeamId -> MH ()

disconnectChannels :: MH ()

Websocket was disconnected, so all channels may now miss some messages

toggleMessageTimestamps :: MH ()

toggleVerbatimBlockTruncation :: MH ()

jumpToPost :: PostId -> MH ()

Given a post ID, switch to that post's channel and select the post in message selection mode.

This function will do what it can to honor the request even when we don't know about the post because it hasn't been fetched, or when the post is in a channel that we aren't a member of. In each case a reasonable effort will be made (fetch the post, join the channel) before giving up.

addMessageToState :: Bool -> Bool -> PostToAdd -> MH PostProcessMessageAdd

Adds a possibly new message to the associated channel contents. Returns an indicator of whether the user should be potentially notified of a change (a new message not posted by this user, a mention of the user, etc.). This operation has no effect on any existing UnknownGap entries and should be called when those are irrelevant.

The first boolean argument (doFetchMentionedUsers) indicates whether this function should schedule a fetch for any mentioned users in the message. This is provided so that callers can batch this operation if a large collection of messages is being added together, in which case we don't want this function to schedule a single request per message (worst case). If you're calling this as part of scrollback processing, you should pass False. Otherwise if you're adding only a single message, you should pass True.

The second boolean argument (fetchAuthor) is similar to the first boolean argument but it refers to the author of the message instead of any user mentions within the message body.

The third argument (newPostData) indicates whether this message is being added as part of a fetch of old messages (e.g. scrollback) or if ti is a new message and affects things like whether notifications are generated and if the "New Messages" marker gets updated.