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
It will make it easier to add addditional fields on the event later
MessageEvent constructor calls are generally quite short, and there are no boring required fields other than an integer id. However, as we add localMessageId to the event, it would be expected to have a boring value most of the time, so prepare for that. A neat side-effect is that we can cut some imports from lib/api/model/. (Some places that use non-zero event IDs now use 0, but we don't care much about this value anyway.)
Strings in general should not be JSON-encoded in Zulip APIs. We will handle local_id separately because that's a bit different.
This will be used for local echoing. It's not yet fully documented; see CZO discussion: https://chat.zulip.org/#narrow/channel/412-api-documentation/topic/local_id.2C.20queue_id.2Fsender_queue_id/near/2135340
MessageStore stands out as a better home for sendMessage, which was on PerAccountStore before we extracted all the separate stores. This will make it more natural to support outbox/local echoing.
This was referenced Apr 1, 2025
PIG208
changed the title
PIG208
changed the title
This is an NFC because UpdateMachine would have thrown (before this change) when the null-check is not on PerAccountStore. This queueId will later be used for local-echoing.
Message will become generic later, which does not support generic factory methods.
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 locally echoed 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<MessageDestination>`. See "least-upper-bound" tagged issues for reference: https://github.com/dart-lang/language/issues?q=state%3Aopen%20label%3A%22least-upper-bound%22
…ableMessage except MessageListMessageItem. This keeps changes minimal, leaving most of the helpers in lib/model/message_list.dart untouched, to avoid unnecessary generalization. We have to make Message.fromJson a static method, because factories do not take type arguments. This causes some issues with the code generator because it does not recognize a static fromJson method. Regarding potential performance impact: StreamMessage.destination and DmMessage.destination both constructs MessageDestination from scratch, to avoid keeping duplicate info in memory. On the flip side, there might be some slight cost of constructing DmMessage.destination for builds when we convert DmMessage.allRecipientIds to lists. Since we are already doing O(N) traversals on the list anyway (see DmRecipientHeader.build), this cost should be negligible.
This is NFC because we don't yet create them when sending messages.
For some narrows, this is in the way of the message handling hot path. This refactor takes care to make sure that calling containsMessage with StreamMessage or DmMessage remains about as efficient as before.
TODOs - Perhaps make senderFullName available on OutboxMessage - Add tests.
TODO fix broken tests; more tests, documentation. This does not debounce new outbox messages. That will be handled in a later commit.
PIG208
changed the title
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.
(This branch can be used to preview the full implementation)
Fixes #1441