dcb5bb7914
The main motivation for this change is to simplify this interface and make it easier to reason about. The case where it affects the behavior is when is_valid_conversation() returns false, while current_recipient and get_recipient() agree on some truthy value. This means the message-content textarea is empty -- in fact the user just cleared it, because we got here from an input event on it -- but the compose box is still open to some PM thread that we have a typing notification still outstanding for. The old behavior is that in this situation we would ignore the fact that the content was empty, and go ahead and prolong the typing notification, by updating our timer and possibly sending a "still typing" notice. This contrasts with the behavior (both old and new) in the case where the content is empty and we *don't* already have an outstanding typing notification, or we have one to some other thread. In that case, we cancel any existing notification and don't start a new one, exactly as if `stop` were called (e.g. because the user closed the compose box.) The new behavior is that we always treat clearing the input as "stopped typing": not only in those cases where we already did, but also in the case where we still have the same recipients. (Which seems like probably the common case.) That seems like the preferable behavior; indeed it's hard to see the point of the "compose_empty" logic if restricted to the other cases. It also makes the interface simpler. Those two properties don't seem like a coincidence, either: the complicated interface made it difficult to unpack exactly what logic we actually had, which made it easy for surprising wrinkles to hang out indefinitely. |
||
|---|---|---|
| .. | ||
| js | ||
| README.md | ||
| package.json | ||
README.md
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.