Tags: glennneiger/zulip-mobile
Tags
webview: Tidy up style and comments for new handshake code. This cleans up a few small things from the parent commit: * Pull the detailed handshake logic out of `componentDidMount` into its own method. * Rename `isWebViewReady` to be a bit more specific, and to have the grammar of a fact rather than a question, as in `if (isReady)` -> "if the thing is ready". * Keep mentions of the MessageInput* types in a consistent order. * Make the comments a lot terser. See the parent commit for detailed explanation of this code.
android: Disable AAPT2 for now, to unblock release builds. This became the default with Android Gradle Plugin version 3.0.0: https://developer.android.com/studio/releases/gradle-plugin#3-0-0 So turning it off returns us to the behavior before we recently took that upgrade. Without this line, we run into this issue when attempting to make a release build: facebook/react-native#16906 That issue was closed long ago when an intended fix was merged, but then that was reverted. The fix went back in as da6a5e043 upstream, which is in v0.57.0, so we'll get it when we take that upgrade; hopefully that then fixes this for real.
webview: Better match the invoke-lightbox logic to the webapp. When the user touches an image in the message list, we've been deciding whether to invoke the lightbox for it based on whether its parent element is a link with `target="_blank"`. This is unsemantic and kind of quirky, and in fact it doesn't always get the right answer; for example, this was causing us to pull up a (failed, blank) lightbox for the avatar in an embedded tweet, or for the giant file-type icon in an embedded Dropbox link. Instead, use the rather more semantically plausible test found in the webapp. Also add a few comments; explain in particular the "video" exceptions. This code still isn't quite right, and the difference shows up in the case of an embedded Dropbox *image*: we should be getting the image URL from, well, the `img` element, but instead we're getting it from the enclosing link, which has a different job and in the case of a Dropbox image points to the `?dl=0` HTML page which displays the image. In that case, a lightbox is the right thing, but because we use the wrong URL we show a blank one. Leave that as a TODO to be fixed separately, along with thumbnailing-awareness.
tools/bump-version: Add auto-commit.
The slick Bash feature with `${...@q}` that I use here for nicely
shell-quoting a value is one I just now learned when looking for
alternatives in the Bash manual. I'd never seen it before; which
turns out to be because it's "only" two years old!
messages: Initialize new state subtrees in migrations. Each migration should take a state that was a valid value of the old `GlobalState` type, and return a state that is a valid value of the new `GlobalState` type. In particular, when we create a new state subtree (i.e. a new property on `GlobalState`), the migration should initialize that subtree. The reason we've largely gotten away without doing this (we've had no migrations at all until recently, so certainly haven't been doing this) is that only a small amount of code is exposed to any failure here -- only REHYDRATE handlers, when handling the `payload` of the action -- because the actual Redux state is always initialized in the standard Redux way, by invoking the handlers with `undefined` previous state. In cases where this is complicated to do, we might choose to skip it in the future too. But here we have an actual, critical, bug that this prevents. When starting up the app, with a state left behind by a version from before these migrations, we never get past the green loading screen; and the log shows `TypeError: Object.values called on non-object` inside a function named `rehydrate`, which must be the one in `flagsReducers`. That's because `action.payload` has no property `messages` -- contrary to our type annotation saying a REHYDRATE action's payload should be a `GlobalState`. And fixing it once and for all in these migrations (rather than worry about future bugs if future changes we make to rehydrate code innocently make this same assumption) is easy. So do that.
PreviousNext