Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

local echo (n/n): Support simplified version of local echo #1453

Draft
wants to merge 16 commits into
base: main
Choose a base branch
from

Conversation

PIG208
Copy link
Member

@PIG208 PIG208 commented Apr 1, 2025

screenshots
message sent got message event
sending-success-before sending-success-after
message failed to send message content tapped recipient headers
send-failed sent-failed-interacted recipient-headers

(This branch can be used to preview the full implementation)

Fixes #1441

@PIG208 PIG208 changed the title Support simplified version a local echo (n/n) Support simplified version of local echo (n/n) Apr 1, 2025
@PIG208 PIG208 changed the title Support simplified version of local echo (n/n) locale echo (n/n): Support simplified version of local echo Apr 1, 2025
@PIG208 PIG208 changed the title locale echo (n/n): Support simplified version of local echo local echo (n/n): Support simplified version of local echo Apr 2, 2025
@PIG208 PIG208 force-pushed the pr-echo branch 10 times, most recently from 66614ca to 21e4b4b Compare April 10, 2025 23:19
PIG208 added 12 commits April 10, 2025 22:20
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.
Also removed a stale comment that refers to resolved issues
(zulip#173 and zulip#175).

We will reuse this helper when handling 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.
PIG208 added 3 commits April 10, 2025 22:40
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
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Simplified local echo, with retry
1 participant