Turn iOS compose box uncontrolled; dedupe with Android

[borisyankov]

A fix for the iOS blocking issue is nowhere in sight, but a cool and simple workaround was discovered that allows us to implement the fix now, and not in an unspecified time in future.

Details are given in the commit messages.

[gnprice]

Thanks! Glad to get these together again :)

A few questions:

• It's the first commit that fixes Chinese and Japanese input don't work on iOS (blocked on RN v0.57) #2434, not the second, right?
• In the second commit, in the iOS case, when text is empty it looks like we end up calling setTimeout(...setNativeProps(...)) with an empty text twice. Perhaps in updateTextInput it should just be like this?

if (text.length === 0) {
  // ...
} else {
  textInput.setNativeProps({ text });
}

• In these comments that mention different RN bugs, let's definitely have links -- either to the upstream bugs, or to our own issue that describes the RN bug when that's a better reference.
• Also, this isn't an "iOS bug" as far as I know -- it's an RN bug specific to iOS. Similarly "Android" doesn't have a bug here. You know that, but I think it's important to be clear about it in the code for other readers -- not only to keep an accurate mental tally of which platforms are responsible for bugs that affect us 😛 , but also because that framing can make a big difference when following the link and reading more details to understand what the story is.
• How confident are you / how are you confident that the double-set trick consistently avoids the issue? The setTimeout in particular makes me wonder if there might be a race where sometimes the relevant bit of RN code runs in between the two sets, and other times it doesn't and the trick doesn't work -- like maybe that bit of RN code runs once per frame, and if we get an update just after that code ran for one frame, and the phone is nice and fast and not busy, the second set happens within the >=8ms before it runs for the next frame.
• On the other side of things, I wonder if a legitimate update could get squeezed in between the two sets, and get clobbered -- like if the user has just one letter there, and hits delete and then a letter in quick succession, and maybe if it's an old and overloaded phone so the JS engine takes a while to get around to the setTimeout'd second set.

[borisyankov]

Indeed it is the first commit that solves #2434, I will reword that.

Hmm, while the code I did commit works correctly, I seem to have missed to change the updateTextInput function completely as intended. I totally wanted to do

  if (text.length === 0) {
    clearTextInput(textInput);
  } else {
    textInput.setNativeProps({ text });
}

[borisyankov]

The setTimeout concern is pretty good to raise! I am researching to see how likely it is to cause this issue.

[gnprice]

Quick update:

• @borisyankov mentioned in chat that he's been able to reproduce cases where the setTimeout did in fact mess up the text input. So, chalk up another candidate workaround for upstream's bug [0.54] TextInput.setNativeProps({text: ''}) no longer works facebook/react-native#18272 that doesn't quite make it. (There's a long line of them in that thread.)
• On the other hand, RN v0.57 has been released, and it has the fix for that bug! So once we upgrade to v0.57, we won't need such workarounds and can just straightforwardly switch to uncontrolled inputs like we have on Android.
• See Upgrade to React Native 0.56 & 0.57 #2789 for the current work on upgrading to RN v0.56 (issue Upgrade to RN 0.56 #2788 ); after that, we'll tackle v0.57.

[gnprice]

I think this makes most sense to track as an issue at this point rather than a PR; when we come back to it I think we'll basically repeat the boring part of this PR and (happily!) skip the more interesting part. So I went and filed #3017 for that.