07322d78a0
This is intended as a pure refactor, making the data flow clearer in preparation for further changes. In particular, this makes it manifest that the calls to `get_recipient` and `is_valid_conversation` don't depend on anything else that has happened during the call to `handle_text_input`. This is indeed a pure refactor because * is_valid_conversation itself has no side effects, either in the implementation in typing.js or in any reasonable implementation, so calling it sooner doesn't affect anything else; * if we do reach it, the only potentially-side-effecting code it's moving before is a call to `stop_last_notification`, and that in turn (with the existing, or any reasonable, implementation of `notify_server_stop`) has no effect on the data consulted by the implementation of `is_valid_conversation`.
The files in this subtree are part of the Zulip web frontend, and are also incorporated by the Zulip mobile app.
Note that the deployment cycles are different:
-
In the webapp, this code is deployed in the same way as the rest of the web frontend: it's part of the server tree, and the browser gets it from the server, so the client is always running the same version the server just gave it.
-
In the mobile app, this code is deployed in the same way as the rest of the mobile app: it's bundled up into the app binary which is uploaded to app stores and users install on their devices. The client will be running the version built into their version of the mobile app, which may be newer, older, or simply different from the version on the server.
The mobile app always refers to a specific version of this code; changes to this code will appear in the mobile app only after a commit in the mobile app pulls them in.