Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zulip/static/shared/js/typing_status.js.flow

19 lines
348 B
Plaintext
Raw Normal View History

shared: Describe interface of typing_status in Flow. This allows the mobile app to stay well-typed while using this code.
2019-10-04 23:37:28 +02:00
/**
* @flow strict
*/
"use strict";
type RecipientUserIds = number[];
type Worker = {|
get_current_time: () => number, // as ms since epoch
notify_server_start: RecipientUserIds => void,
notify_server_stop: RecipientUserIds => void
|};
typing_status: Write jsdoc for main entry point, and rename. This was named after when it gets called from the UI, rather than after what it can be expected to do. Naming it after what it's meant to do -- and giving a summary line to expand on that -- provides a more helpful semantic idea for reasoning about the function. Doubly so for using the function in a different client with its own UI, like the mobile app.
2019-10-22 02:38:51 +02:00
declare export function update(
typing_status: Use parameters for data rather than callbacks. The real purpose these two callbacks serve is exactly what an ordinary parameter is perfect for: * Each has just one call site, at the top of the function. * They're not done for side effects; the point is what they return. * The function doesn't pass them any arguments of its own, or otherwise express any internal knowledge that doesn't just as properly belong to its caller. So, push the calls to these callbacks up into the function's caller, and pass in the data they return instead. This greatly simplifies the interface of `handle_text_input` and of `typing_status` in general.
2019-10-21 23:03:19 +02:00
worker: Worker,
typing_status: Switch sentinel "recipient" value to `null`. This feels a bit more semantically appropriate: it more clearly says "here's some information: there is no (relevant) recipient", rather than "no information available". (Both `null` and `undefined` in JS can have either meaning, but `undefined` especially commonly means the latter.) Concretely, it ensures a bit more explicitness where the value originates: a bare `return;` becomes `return null;`, reflecting the fact that it is returning a quite informative value. Also make the implementation more explicit about what's expected here, replacing truthiness tests with `!== null`. (A bit more idiomatic would be `!= null`, which is equivalent when the value is well-typed and a bit more robust to ill-typing bugs. But lint complains about that version.)
2019-10-22 02:52:01 +02:00
new_recipient: RecipientUserIds | null
typing_status: Use parameters for data rather than callbacks. The real purpose these two callbacks serve is exactly what an ordinary parameter is perfect for: * Each has just one call site, at the top of the function. * They're not done for side effects; the point is what they return. * The function doesn't pass them any arguments of its own, or otherwise express any internal knowledge that doesn't just as properly belong to its caller. So, push the calls to these callbacks up into the function's caller, and pass in the data they return instead. This greatly simplifies the interface of `handle_text_input` and of `typing_status` in general.
2019-10-21 23:03:19 +02:00
): void;