Edit-message (7/n): Implement edit-message methods on MessageStore #1484
Conversation
|
|
chrisbobbe
changed the title
chrisbobbe
force-pushed
the
pr-edit-message-7
branch
from
a5262ab to
45b4b05
Compare
chrisbobbe
force-pushed
the
pr-edit-message-7
branch
from
45b4b05 to
ea74a55
Compare
|
Revision pushed, this time putting the tests in test/model/message_test.dart instead of test/model/store_test.dart (but still testing against the whole |
| String? takeFailedMessageEdit(int messageId) { | ||
| final status = _editMessageRequests.remove(messageId); | ||
| if (status == null) { | ||
| throw StateError('called takeFailedEdit, but no edit'); |
There was a problem hiding this comment.
nit: this doesn't match the name of the method: takeFailedMessageEdit
| // Request has succeeded; event hasn't arrived | ||
| check(store.getEditMessageErrorStatus(message.id)).isNotNull().isFalse(); |
There was a problem hiding this comment.
I feel that we can be a bit more certain that the request has complete by awaiting its future. But I guess editMessage doesn't return it because the UI code doesn't need the future.
There was a problem hiding this comment.
Yeah, there's nothing user-facing to do when the future succeeds (we take the event as signaling edit-message success), so editMessage doesn't return it.
| await updateMessage(connection, messageId: messageId, content: content); | ||
| // On success, we'll clear `status` from editMessageRequests | ||
| // when we get the event. | ||
| } catch (e) { |
There was a problem hiding this comment.
I can see why an error dialog isn't needed. The error text is shown immediately when the edit request fails. I wonder if the e is something more interesting/unexpected, do we want to log it?
| check(store.getEditMessageErrorStatus(message.id)).isNull(); | ||
| })); | ||
|
|
||
| test('request failure before event arrival; take failed edit in between', () => awaitFakeAsync((async) async { |
There was a problem hiding this comment.
nit: the format "request fails, then message deleted" seems preferable to me to help understand the sequence of events
| check(store.getEditMessageErrorStatus(message.id)).isNull(); | ||
| })); | ||
|
|
||
| test('takeFailedMessageEdit throws StateError when nothing to take', () => awaitFakeAsync((async) async { |
There was a problem hiding this comment.
I think a similarly useful test would be repeated editMessage calls that operate on the same message.
| store = eg.store(); | ||
| connection = store.connection as FakeApiConnection; | ||
| message = eg.streamMessage(); | ||
| await store.addMessage(message); |
There was a problem hiding this comment.
I think we can also test if the listeners are notified whenever an update is expected.
| /// See also: | ||
| /// * [getEditMessageErrorStatus] | ||
| /// * [takeFailedMessageEdit] | ||
| void editMessage({required int messageId, required String content}); |
There was a problem hiding this comment.
I think we should document the condition when you should not call editMessage (like we do for takeFailedMessageEdit), i.e., when there is a current edit message request.
This PR, toward the edit-message feature #126, implements three new methods on
MessageStore:editMessage, to be called when the user taps the "Edit message" button in the message action sheet:getEditMessageErrorStatus, to be called when rendering the message list; showing a loading state when we haven't gotten the update-message event yet, and an error state for a failed edit request:(The UI text isn't final; see updates on CZO: #mobile-design > edit message @ 💬)
takeFailedMessageEdit, to be called when you tap the error message pictured above, so we can put you back in the edit box, starting with the text you'd tried to edit to. This part is from CZO discussion: #mobile-design > edit message @ 💬Related: #126