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 :: 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.