local echo (n/n): Support simplified version of local echo #1453
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Apr 1, 2025
PIG208
changed the title
PIG208
changed the title
PIG208
changed the title
PIG208
force-pushed
the
pr-echo
branch
10 times, most recently
from
66614ca to
21e4b4b
Compare
Message will become generic later, which does not support generic factory methods. We will add a comment explaining it then.
This is unused in app code. This is mostly NFC except that we will ignore fields other than "id" from the list of objects from "display_recipient" on message objects from the server.
This will help support outbox messages in MessageListView later. We extracted Conversation instead of using MessageDestination because they are foundamentally different. Conversation is the identifier for the conversation that contains the message from, for example, get-messages or message events, but MessageDestination is specifically for send-message.
See also CZO discussion on the design of this, and the drawbacks of the alternatives: https://chat.zulip.org/#narrow/channel/243-mobile-team/topic/A.20new.20variant.20of.20Zulip.20messages.20-.20inheritance.20structure/with/2141288 This will help support outbox messages in MessageListView later. This requiring specifying the element type of `List`s in some tests (or in some cases, the type of a variable declared). This is a side effect of making `StreamMessage` and `DmMessage` extend `Message<T>` with different `T`'s. When both appear in the same `List`, the upper bound is `Object`, instead of the more specific `Message<Conversation>`. See "least-upper-bound" tagged issues for reference: https://github.com/dart-lang/language/issues?q=state%3Aopen%20label%3A%22least-upper-bound%22
…Base except MessageListMessageItem. This keeps changes minimal, leaving most of the helpers in lib/model/message_list.dart untouched, to avoid unnecessary generalization. This hoists streamId in StreamMessageRecipientHeader.build, where we used to access streamId via message instead from the onLongPress callback. Because Message.streamId only changes on message moves, we expect the build method to be called again, so this should be fine.
While we do create outbox messages, there are in no way user-visible changes since the outbox messages don't end up in message list views. We create skeletons for helpers needed from message list view, but don't implement them yet, to make the diff smaller. --- OutboxMessage is designed to keep the timers internal to itself, and expose only the callback functions, to keep message store code simple. To make sure that OutboxMessage.dispose is always called when the outbox message is removed from the store, we expose an unmodifiable view of the actual map. For testing, similar to TypingNotifier.debugEnabled, we add MessageStoreImpl.debugOutboxEnabled in case a test does not intend to cover outbox messages.
This is an NFC because MessageListMessageItem is still the only subclass of it.
This will make MessageItem compatible with other future subclasses of MessageBase, in particular OutboxMessage, which do not need unread markers.
This adds some overhead in magnitude of O(1) (where the constant is the number of outbox messages in a view, expected to be small) on message event handling. We add outboxMessages as a list independent from messages on _MessageSequence. Because outbox messages are not rendered (the raw content is shown as plain text), we leave the 1-1 relationship between `messages` and `contents` unchanged. When computing `items`, we now start to look at `outboxMessages` as well, with the guarantee that the items related to outbox messages always come after those for other messages. Look for places that call `_processOutboxMessage(int index)` for references, and the changes to `checkInvariants` on how this affects the message list invariants. `handleOutboxMessage`, similar to `handleMessage`, also look at `fetched` before adding the outbox message. However, there is no data race to prevent — we can totally not clear `outboxMessages` in `_reset`, and do the initial fetch from `MessageListView.init`, so that outbox messages do not rely on the fetched state at all. I decided against it since it is easy to check `fetched`, and making `fetchInitial` reprocess `outboxMessages` from a clean state (which is inexpensive) helps ensuring message list invariants.
See if the tests can be simplified
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
screenshots
(This branch can be used to preview the full implementation)
Fixes #1441