-
Notifications
You must be signed in to change notification settings - Fork 307
Prep for supporting set typing status #888
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
lib/model/typing_status.dart
Outdated
} | ||
|
||
Future<void> _notifyStart(PerAccountStore store) async { | ||
_nextStartTime = DateTime.now().add(typingStartedWaitPeriod); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quick high-level comment: let's write this so that we definitely don't have to think about time zones to reason about it. 🙂
I think an OK version could be made with DateTime.timestamp()
, which uses UTC. Probably a cleaner approach is to use Stopwatch
— then we're really not thinking about calendar dates or anything like that, just elapsed durations, which is exactly right for this subsystem.
382289d
to
fe71eea
Compare
Moved the main commits to #897, so that we can get some earlier independent changes reviewed separately. |
58a36d9
to
e19c4de
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Comments below.
test/api/fake_api.dart
Outdated
@@ -29,11 +29,11 @@ class _PreparedSuccess extends _PreparedResponse { | |||
/// An [http.Client] that accepts and replays canned responses, for testing. | |||
class FakeHttpClient extends http.BaseClient { | |||
|
|||
http.BaseRequest? lastRequest; | |||
List<http.BaseRequest> requestHistory = []; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be helpful to make this a getter that returns an Iterable
, which is backed by a private field that's a List? Then consumers of the request history can't mess with things by modifying the list.
test/api/fake_api.dart
Outdated
// TODO: Prevent a source of bugs by ensuring that there is no outstanding | ||
// prepared responses when the test ends. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: "that there are no outstanding prepared responses"
lib/api/route/typing.dart
Outdated
return connection.post('setTypingStatus', (_) {}, 'typing', { | ||
'op': RawParameter(op.toJson()), | ||
'to': destination.userIds, | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the effect of not passing 'type' in the DM case? From the doc, it looks like the preferred client behavior (assuming Zulip Server 4+) is to pass 'private' when FL is <174, else 'direct'. I'm not sure I've read closely enough to know what happens across the range of supported servers if we just don't pass 'type' at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was intended to match the mobile apps' implementation, where we omit the type field for dm typing notifications. I think it is not clear that the default was "private" back then. Skipping type
this way allows us to not worry about the "private" -> "direct" transition of this API.
See: https://chat.zulip.org/#narrow/stream/378-api-design/topic/stream.20typing.20indicator
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. I guess since zulip-mobile does that not-preferred thing and presumably still works, probably makes it harmless if we also do the not-preferred thing. 🙂 But also, the burden of handling the "private" -> "direct" transition isn't heavy—
pass 'private' when FL is <174, else 'direct'
—so I'd be in favor of just doing that. If not, though, let's include a comment to make it clear that we're intentionally doing something that's different from the thing that seems natural/expected from a reading of the API doc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, cleanest to just do the thing that's preferred in the current API.
(And then adapt for old servers as necessary — but "type" has been accepted since server-4, so effectively forever now.)
lib/api/route/typing.dart
Outdated
return connection.post('setTypingStatus', (_) {}, 'typing', { | ||
'type': RawParameter((supportsTypeChannel) ? 'channel' : 'stream'), | ||
'op': RawParameter(op.toJson()), | ||
'stream_id': destination.streamId, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The API doc says 'stream_id' is new in FL 215, and there's a different way we need to express the destination for <215.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting, thanks for catching that!
test/api/route/typing_test.dart
Outdated
destination: destination, | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
destination: destination, | |
); | |
destination: destination); |
test/api/route/typing_test.dart
Outdated
}, | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
}, | |
); | |
}); |
6ff98a9
to
3bac13a
Compare
Thanks for the review @chrisbobbe! I have updated the PR.
|
Thanks! I should push an update later addressing these comments. |
eec2173
to
c823d5c
Compare
OK, this has been updated :) |
Fixed indentation in a test. |
Pushed to rebase. |
2a349d8
to
9a77275
Compare
Dropped the |
lib/api/route/typing.dart
Outdated
final supportsTypeChannel = connection.zulipFeatureLevel! >= 248; // TODO(server-9) | ||
final supportsStreamId = connection.zulipFeatureLevel! >= 215; // TODO(server-8) | ||
return connection.post('setTypingStatus', (_) {}, 'typing', { | ||
'type': RawParameter((supportsTypeChannel) ? 'channel' : 'stream'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: extra parens
lib/api/route/typing.dart
Outdated
'topic': RawParameter(destination.topic), | ||
...(supportsStreamId) ? {'stream_id': destination.streamId} | ||
: {'to': [destination.streamId]} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: put in logical order: channel/stream ID before topic, because the topic lives within the channel
Similarly, put type
just above the channel ID (or list of DM recipients), because it's the next layer of namespacing above those.
lib/api/route/typing.dart
Outdated
...(supportsStreamId) ? {'stream_id': destination.streamId} | ||
: {'to': [destination.streamId]} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A fun Dart 3 way to write this:
...(supportsStreamId) ? {'stream_id': destination.streamId} | |
: {'to': [destination.streamId]} | |
if (supportsStreamId) 'stream_id': destination.streamId | |
else 'to': [destination.streamId], |
test/api/route/typing_test.dart
Outdated
Future<void> checkSetTypingStatus(FakeApiConnection connection, TypingOp op, { | ||
required MessageDestination destination, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit:
Future<void> checkSetTypingStatus(FakeApiConnection connection, TypingOp op, { | |
required MessageDestination destination, | |
Future<void> checkSetTypingStatus(FakeApiConnection connection, | |
TypingOp op, { | |
required MessageDestination destination, |
else "op" gets a bit lost visually
test/api/route/typing_test.dart
Outdated
Future<void> checkSetTypingStatusForTopic(TypingOp op, String expectedOp) => | ||
FakeApiConnection.with_((connection) => | ||
checkSetTypingStatus(connection, op, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: block bodies
see that Flutter style guide section I've linked a few times before 🙂
test/api/route/typing_test.dart
Outdated
test('send typing status start for topic', () => | ||
checkSetTypingStatusForTopic(TypingOp.start, 'start')); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And definitely block bodies for test cases.
lib/api/route/typing.dart
Outdated
return connection.post('setTypingStatus', (_) {}, 'typing', { | ||
'op': RawParameter(op.toJson()), | ||
'to': destination.userIds, | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, cleanest to just do the thing that's preferred in the current API.
(And then adapt for old servers as necessary — but "type" has been accepted since server-4, so effectively forever now.)
Thanks @PIG208, and thanks @chrisbobbe for the previous reviews! Generally this all looks good. Several comments above, all small. |
Thanks! Pushed an update to the last commit. |
UserSettingName has been moved to another file. Signed-off-by: Zixuan James Li <[email protected]>
Signed-off-by: Zixuan James Li <[email protected]>
This is not prohibited by the server and we should not log expected behaviors like this. See: https://zulip.com/api/get-events#typing-start Signed-off-by: Zixuan James Li <[email protected]>
Signed-off-by: Zixuan James Li <[email protected]>
An issue that exists prior to this change is that there can be unused prepared responses when the test ends, but we don't have a way to detect that. We can potentially do something like what testWidgets does with pending timers. Signed-off-by: Zixuan James Li <[email protected]>
The three legacy cases will need to be dropped separately at different server versions. The tests will fail accordingly as we do that. Signed-off-by: Zixuan James Li <[email protected]>
Thanks! Looks good; merging. |
No description provided.