Handle UpdateMessageEvent in MessageListView (#118) #238

oxling · 2023-07-24T15:30:57Z

This propagates the UpdateMessageEvent to the MessageListView, allowing you to see changes to your messages in real time.

Putting this up as a draft, since I have a few questions - leaving my comments inline.

Fixes: #118

lib/model/message_list.dart

gnprice

Thanks @oxling! See replies below.

lib/model/message_list.dart

lib/api/model/model.dart

lib/model/message_list.dart

gnprice · 2023-07-24T21:15:36Z

(Also, just to be explicit: we'll want some unit tests for this change. Perfectly reasonable to have left them out when it's a draft, though.)

oxling · 2023-07-24T22:41:40Z

(Also, just to be explicit: we'll want some unit tests for this change. Perfectly reasonable to have left them out when it's a draft, though.)

Will do before I mark this as ready!

lib/model/message_list.dart

oxling · 2023-07-25T16:25:32Z

OK, this is all of the requested changes, except for the unit test. I just threw a message in #mobile-team about doing that - I'm a little stuck on how to proceed getting that test stubbed out correctly.

test/model/message_list_test.dart

gnprice

Thanks @oxling! Comments below.

lib/model/message_list.dart

test/model/message_list_test.dart

gnprice · 2023-07-26T20:53:45Z

Pardon all of my force pushes here - sorry, this would have made more sense to make individual edits and then squash them all before merging.

Yeah, that'd be a very reasonable workflow — but this force-push workflow is actually our usual one, so it's no problem at all.

That's because we often have a PR that should end up as several commits, e.g. because it make preparatory refactors, or adds a feature in one place and then another feature that builds on that. So in order to support those, our usual workflow is that each revision is a new draft of the whole final sequence of commits to merge, which means the author squashes edits in.

That does cause GitHub to be less helpful about comparing different revisions. The reviewer instead relies on having fetched a local copy, and we have a couple of scripts to help make that easy.

oxling · 2023-07-26T22:00:11Z

Pardon all of my force pushes here - sorry, this would have made more sense to make individual edits and then squash them all before merging.

Yeah, that'd be a very reasonable workflow — but this force-push workflow is actually our usual one, so it's no problem at all.

That's because we often have a PR that should end up as several commits, e.g. because it make preparatory refactors, or adds a feature in one place and then another feature that builds on that. So in order to support those, our usual workflow is that each revision is a new draft of the whole final sequence of commits to merge, which means the author squashes edits in.

That does cause GitHub to be less helpful about comparing different revisions. The reviewer instead relies on having fetched a local copy, and we have a couple of scripts to help make that easy.

Ah, interesting. Normally I use a lot of Github's "since you last checked" feature to do reviews.

test/model/message_list_test.dart

oxling · 2023-07-26T22:32:39Z

OK, assuming I got the test state issue sorted out correctly, this is ready for round three!

gnprice

Thanks @oxling for the revision!

I think at this point the behavior all looks good. Some substantive comments about the tests, as well as various comments for clarity and style; see details below.

test/model/message_list_test.dart

gnprice · 2023-07-28T01:24:56Z

test/model/message_list_test.dart

+      final mockMessage = eg.streamMessage(id: 972, stream: stream, content: oldContent);
+      final messageList = await messageListViewWithMessages([mockMessage], store, narrow);
+
+      final updateEvent = UpdateMessageEvent(


Let's also include an explicit renderingOnly: null in this test event, since that's a key part of the data this test case wants.

Ah my assumption was that for older server versions, it will omit the renderingOnly key entirely.

Ah. Yeah, the server will leave it out of its response — old servers don't know about anything named rendering_only. But then in the UpdateMessageEvent object that we deserialize from the server's JSON, that class has a field renderingOnly with type bool?:

final bool? renderingOnly; // TODO(server-5)

which means the object will always have some value in a spot called renderingOnly, and that value is of type bool? — which means it's either null or a value of type bool.

So when we deserialize the JSON and there's no rendering_only key in that JSON object, the value we use for the renderingOnly field in the resulting UpdateMessageEvent is naturally null.

This does mean that if a key is present in some JSON object but with a value of null, we usually don't distinguish that from the key being absent — either one will deserialize to a field with value null. This has been fine, because it's rare for an API to have both those possibilities for a given key and have them mean different things. (Certainly it's rare in the Zulip API, and I'd expect it to be rare in sane APIs generally.) There's only one such instance I can think of in the Zulip API; here's discussion on how we expect to handle it:
https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/flutter.3A.20omitted.20vs.2E.20null.20in.20JSON/near/1551522

In this test, if there weren't a way to express explicitly in the code that this event came without a (non-null) rendering_only, I'd want to still make it explicit by using a comment — like

// renderingOnly omitted

at the spot where the renderingOnly: true, (or whatever) would have appeared.

gnprice · 2023-07-28T01:31:00Z

test/model/message_list_test.dart

+      //Before the first element
+      var idx = messageList.findMessageWithId(1);
+      check(idx).equals(-1);
+
+      //Is the first element
+      idx = messageList.findMessageWithId(2);
+      check(idx).equals(0);


I think this test's code can become easier to read by making it a lot more compact — one line per check, rather than four. Like so:

check(messageList.findMessageWithId(1)).equals(-1); //Before the first element check(messageList.findMessageWithId(2)).equals(0); //Is the first element

but really at that point I think the comments become unnecessary, so:

Suggested change

//Before the first element

var idx = messageList.findMessageWithId(1);

check(idx).equals(-1);

//Is the first element

idx = messageList.findMessageWithId(2);

check(idx).equals(0);

check(messageList.findMessageWithId(1)).equals(-1);

check(messageList.findMessageWithId(2)).equals(0);

(Unnecessary because now the query arguments are nicely aligned next to each other, and also all not too many lines after the setup of the list of messages so the eye can easily look back and forth between those.)

gnprice · 2023-07-28T01:36:07Z

test/model/message_list_test.dart

+      final updatedMessage = messageList.messages[0];
+      check(updatedMessage).identicalTo(message);
+      check(listenersNotified).equals(true);
+
+      check(message)
+        ..content.equals(newContent)


The listeners-notified check feels like it's interrupting here between a group of checks that are more closely related to each other. I think it becomes easier to see what's being checked if the listenersNotified check comes first (or at the end might work too).

Then we can also group together the updated-message checks more closely by making them a single check call:

Suggested change

final updatedMessage = messageList.messages[0];

check(updatedMessage).identicalTo(message);

check(listenersNotified).equals(true);

check(message)

..content.equals(newContent)

check(listenersNotified).equals(true);

check(messageList.messages[0])

..identicalTo(message)

..content.equals(newContent)

gnprice · 2023-07-28T01:38:17Z

test/model/message_list_test.dart

+      check(message).content.equals(oldContent);
+
+    });
+    test('rendering-only update does not change timestamp', () async {


nits: blank line separating these two multi-line calls; and generally no blank line at end of a block of statements (like the function-expression body that's ending here):

Suggested change

check(message).content.equals(oldContent);

});

test('rendering-only update does not change timestamp', () async {

check(message).content.equals(oldContent);

});

test('rendering-only update does not change timestamp', () async {

gnprice · 2023-07-28T04:19:55Z

test/model/message_list_test.dart

+        userId: userId
+      );


nit: use trailing comma

Suggested change

userId: userId

);

userId: userId,

);

gnprice · 2023-07-28T04:35:42Z

test/model/message_list_test.dart

+  const narrow = StreamNarrow(streamId);
+  final stream = eg.stream(streamId: streamId);


We can avoid needing a magic-number constant for the stream ID by putting these in the opposite order, to make the stream object available:

Suggested change

const narrow = StreamNarrow(streamId);

final stream = eg.stream(streamId: streamId);

final stream = eg.stream();

final narrow = StreamNarrow(stream.streamId);

gnprice · 2023-07-28T04:39:11Z

test/model/message_list_test.dart

+        messageId: 972,
+        messageIds: [972],


I like the approach you took in one of the test cases above: instead of writing out a magic number as message ID that crucially happens to be the same number as used in the original message, refer directly to the original message object and its id property. That helps make it clear that the point is it's the same message.

gnprice · 2023-07-28T04:41:23Z

test/model/message_list_test.dart

+        messageId: 972,
+        messageIds: [972],


Conversely, here the point is that it's not the same message ID, and it'd be good to make that explicit too.

One way to do that would be something like:

messageId: message.id + 1,

test/model/message_list_test.dart

oxling · 2023-07-28T21:05:47Z

OK, addressed the last round of changes!

gnprice

Thanks @oxling for the revision! This is quite close now; just a handful of small comments below.

gnprice · 2023-07-28T23:25:11Z

lib/model/message_list.dart

@@ -1,5 +1,7 @@
+import 'package:collection/collection.dart';


The analyzer now complains this import is unused. (In VS Code, you should be getting a corresponding warning — a yellow squiggle here on the code, and yellow highlighting on the filename.)

gnprice · 2023-07-29T00:03:18Z

lib/model/message_list.dart

+    }
+
+  }


nit: stray blank line

Suggested change

}

}

}

}

gnprice · 2023-07-29T00:07:59Z

lib/model/message_list.dart

+    // not the user.
+
+    // TODO(server-5): Cut this fallback; rely on renderingOnly from FL 114
+    final isRenderingOnly = event.renderingOnly ?? (event.userId == null);
+
+    if (event.editTimestamp != null && !isRenderingOnly) {


Let's join these as one stanza:

Suggested change

// not the user.

// TODO(server-5): Cut this fallback; rely on renderingOnly from FL 114

final isRenderingOnly = event.renderingOnly ?? (event.userId == null);

if (event.editTimestamp != null && !isRenderingOnly) {

// not the user.

//

// TODO(server-5): Cut this fallback; rely on renderingOnly from FL 114

final isRenderingOnly = event.renderingOnly ?? (event.userId == null);

if (event.editTimestamp != null && !isRenderingOnly) {

so that the remaining blank lines in the function delimit the updates to the various fields from each other.

(And I guess part of this corresponds to my previous comment at https://github.com/zulip/zulip-flutter/pull/238/files#r1274275108 .)

gnprice · 2023-07-29T00:11:27Z

lib/model/message_list.dart

+    final idx = findMessageWithId(event.messageId);
+
+    if (idx == -1)  {


nit: let's group these as one stanza:

Suggested change

final idx = findMessageWithId(event.messageId);

if (idx == -1) {

final idx = findMessageWithId(event.messageId);

if (idx == -1) {

gnprice

Ah, and there are a few items from the previous round of review which are still open; see below.

gnprice · 2023-08-01T17:49:51Z

test/model/message_list_test.dart

+      final mockMessage = eg.streamMessage(id: 972, stream: stream, content: oldContent);
+      final messageList = await messageListViewWithMessages([mockMessage], store, narrow);
+
+      final updateEvent = UpdateMessageEvent(


gnprice · 2023-08-01T17:51:25Z

lib/model/message_list.dart

+    // not the user.
+
+    // TODO(server-5): Cut this fallback; rely on renderingOnly from FL 114
+    final isRenderingOnly = event.renderingOnly ?? (event.userId == null);
+
+    if (event.editTimestamp != null && !isRenderingOnly) {


(And I guess part of this corresponds to my previous comment at https://github.com/zulip/zulip-flutter/pull/238/files#r1274275108 .)

gnprice · 2023-08-01T17:57:04Z

lib/model/message_list.dart

+    message.flags = event.flags;
+
+    if (event.renderedContent != null) {
+      assert(message.contentType == 'text/html', "Expected message to have contentType 'text/html'. Instead, got ${message.contentType}");


This will have quotes around the expected value, but not around the actual value. That seems confusing; better to have quotes around either neither or both.

Also let's break this onto two lines, because the line is quite long. In my previous comment I included a suggested version which did that:
#238 (comment)

Processes an UpdateMessageEvent and hands it off to the MessageListView to update, if the message is visible in the MessageListView. Fixes: zulip#118

Also put them consistently in the terminology found in the API doc.

gnprice · 2023-08-03T20:16:10Z

OK, merged with those tweaks. I also included a comment-only change on top, as well as a small comment-only change elsewhere that that reminded me of the need for. (Generally our practice is that comment-only changes don't require code review; if that other change affected more than comments, I'd have sent it as a separate PR instead.) Thanks again @oxling for your work on this!

oxling commented Jul 24, 2023

View reviewed changes

lib/model/message_list.dart Outdated Show resolved Hide resolved

oxling commented Jul 24, 2023

View reviewed changes

lib/model/message_list.dart Outdated Show resolved Hide resolved

oxling commented Jul 24, 2023

View reviewed changes

lib/model/message_list.dart Outdated Show resolved Hide resolved

oxling commented Jul 24, 2023

View reviewed changes

lib/model/message_list.dart Outdated Show resolved Hide resolved

oxling force-pushed the feature/adyer/118/handle-UpdateMessageEvent branch from 4e3e99b to 456c7e4 Compare July 24, 2023 18:34

oxling commented Jul 24, 2023

View reviewed changes

lib/model/message_list.dart Outdated Show resolved Hide resolved

gnprice reviewed Jul 24, 2023

View reviewed changes

oxling force-pushed the feature/adyer/118/handle-UpdateMessageEvent branch 4 times, most recently from 8e034c4 to c952a6a Compare July 25, 2023 15:21

oxling commented Jul 25, 2023

View reviewed changes

lib/model/message_list.dart Outdated Show resolved Hide resolved

oxling commented Jul 25, 2023

View reviewed changes

lib/model/message_list.dart Outdated Show resolved Hide resolved

oxling commented Jul 25, 2023

View reviewed changes

lib/model/message_list.dart Show resolved Hide resolved

oxling commented Jul 25, 2023

View reviewed changes

lib/model/message_list.dart Outdated Show resolved Hide resolved

oxling force-pushed the feature/adyer/118/handle-UpdateMessageEvent branch from c952a6a to 0b1209e Compare July 25, 2023 15:24

oxling force-pushed the feature/adyer/118/handle-UpdateMessageEvent branch from 0b1209e to 6c3d733 Compare July 25, 2023 19:43

oxling commented Jul 25, 2023

View reviewed changes

test/model/message_list_test.dart Show resolved Hide resolved

oxling marked this pull request as ready for review July 25, 2023 19:44

oxling force-pushed the feature/adyer/118/handle-UpdateMessageEvent branch from 6c3d733 to 832fb98 Compare July 26, 2023 01:18

oxling requested a review from gnprice July 26, 2023 01:19

gnprice reviewed Jul 26, 2023

View reviewed changes

oxling force-pushed the feature/adyer/118/handle-UpdateMessageEvent branch 5 times, most recently from 90257cf to 5629234 Compare July 26, 2023 20:12

oxling force-pushed the feature/adyer/118/handle-UpdateMessageEvent branch 3 times, most recently from a045cc7 to c339c0a Compare July 26, 2023 20:52

oxling force-pushed the feature/adyer/118/handle-UpdateMessageEvent branch 2 times, most recently from 0b91ab9 to 5df994d Compare July 26, 2023 22:20

oxling commented Jul 26, 2023

View reviewed changes

test/model/message_list_test.dart Show resolved Hide resolved

oxling changed the title ~~#118: Handle UpdateMessageEvent in MessageListView~~ msglist: Handle UpdateMessageEvent in MessageListView (#118) Jul 26, 2023

oxling changed the title ~~msglist: Handle UpdateMessageEvent in MessageListView (#118)~~ Handle UpdateMessageEvent in MessageListView (#118) Jul 26, 2023

oxling force-pushed the feature/adyer/118/handle-UpdateMessageEvent branch from 5df994d to 2925113 Compare July 26, 2023 22:30

oxling requested a review from gnprice July 26, 2023 22:32

oxling force-pushed the feature/adyer/118/handle-UpdateMessageEvent branch from 2925113 to d6144bb Compare July 26, 2023 22:34

gnprice reviewed Jul 28, 2023

View reviewed changes

oxling force-pushed the feature/adyer/118/handle-UpdateMessageEvent branch from d6144bb to 46e7b7b Compare July 28, 2023 21:05

oxling force-pushed the feature/adyer/118/handle-UpdateMessageEvent branch from 46e7b7b to c463d5d Compare July 28, 2023 21:06

gnprice reviewed Jul 31, 2023

View reviewed changes

gnprice reviewed Aug 1, 2023

View reviewed changes

oxling and others added 3 commits August 3, 2023 12:56

msglist: Handle edited messages in view-model

cff73ee

Processes an UpdateMessageEvent and hands it off to the MessageListView to update, if the message is visible in the MessageListView. Fixes: zulip#118

api [nfc]: Systematically link to docs on event classes

ee01b44

msglist [nfc]: Tighten comments on rendering-only updates

1fc230f

Also put them consistently in the terminology found in the API doc.

gnprice force-pushed the feature/adyer/118/handle-UpdateMessageEvent branch from c463d5d to 1fc230f Compare August 3, 2023 20:14

gnprice merged commit 1fc230f into zulip:main Aug 3, 2023

chrisbobbe mentioned this pull request Aug 3, 2023

Add Reaction class; uncomment Message.reactions and update on events #256

Merged

This was referenced Aug 4, 2023

Clean up and tighten UpdateMessageEvent tests #258

Merged

msglist test: Backfill tests for rest of model; overhaul test setup #260

Merged

gnprice mentioned this pull request Aug 14, 2023

Require Zulip Server 5 #268

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Handle UpdateMessageEvent in MessageListView (#118) #238

Handle UpdateMessageEvent in MessageListView (#118) #238

oxling commented Jul 24, 2023 •

edited by gnprice

Loading

gnprice left a comment

gnprice commented Jul 24, 2023

oxling commented Jul 24, 2023

oxling commented Jul 25, 2023

gnprice left a comment

gnprice commented Jul 26, 2023

oxling commented Jul 26, 2023

oxling commented Jul 26, 2023

gnprice left a comment

gnprice Jul 28, 2023

oxling Jul 28, 2023

gnprice Jul 28, 2023

gnprice Jul 28, 2023

gnprice Aug 1, 2023

gnprice Jul 28, 2023

gnprice Jul 28, 2023

gnprice Jul 28, 2023

gnprice Jul 28, 2023

gnprice Jul 28, 2023

gnprice Jul 28, 2023

gnprice Jul 28, 2023

oxling commented Jul 28, 2023

gnprice left a comment

gnprice Jul 28, 2023

gnprice Jul 29, 2023

gnprice Jul 29, 2023

gnprice Aug 1, 2023

gnprice Jul 29, 2023

gnprice left a comment

gnprice Aug 1, 2023

gnprice Aug 1, 2023

gnprice Aug 1, 2023

gnprice commented Aug 3, 2023

		const narrow = StreamNarrow(streamId);
		final stream = eg.stream(streamId: streamId);

-    }
-  }
+    }
+  }

		final idx = findMessageWithId(event.messageId);

		if (idx == -1) {

Handle UpdateMessageEvent in MessageListView (#118) #238

Handle UpdateMessageEvent in MessageListView (#118) #238

Conversation

oxling commented Jul 24, 2023 • edited by gnprice Loading

gnprice left a comment

Choose a reason for hiding this comment

gnprice commented Jul 24, 2023

oxling commented Jul 24, 2023

oxling commented Jul 25, 2023

gnprice left a comment

Choose a reason for hiding this comment

gnprice commented Jul 26, 2023

oxling commented Jul 26, 2023

oxling commented Jul 26, 2023

gnprice left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oxling commented Jul 28, 2023

gnprice left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gnprice left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gnprice commented Aug 3, 2023

oxling commented Jul 24, 2023 •

edited by gnprice

Loading