Upgrade to RN v0.63 #4245

chrisbobbe · 2020-09-02T00:52:03Z

~~We won't start real work on this until the upgrade to v0.62, #3782, is complete.~~ Done!

Released 2020-07-06.

Release announcement
Changelog
Upgrade guide (the diff doesn't look huge, and big chunks of it make sense at a glance!!)

Looks like we'll get:

LogBox, a nice-looking new way to see errors, warnings, and logs
Pressable, a new API that helps React Native apps' interactions seem more purely native
Native Colors (PlatformColor, DynamicColorIOS), an API for grabbing system-defined colors from the native platform
Dropping iOS 9 and Node.js 8 support. Both of these are fine; we're targeting iOS 10.3 (see top of ios/Podfile), and we're on Node 12
Changed iOS LaunchScreen from xib to storyboard (we did this in Add splash screen for before React has started up #2756)
Flow v0.122 (see changelog)

The text was updated successfully, but these errors were encountered:

chrisbobbe · 2020-09-02T01:08:01Z

We'll get at least one Flow bug fixed:

Merging two variables with same indexer does not work facebook/flow#8178 (see discussion)

We add `typeof` in several places to address this Flow error that starts appearing at the RN and Flow upgrade: ``` Cannot use `TextInput` as a type. A name can be used as a type only if it refers to a type definition, an interface definition, or a class definition. To get the type of a non-class value, use `typeof`. ``` I'm not sure if this is due to the Flow upgrade or to changes React Native made to `TextInput`, or both. Several changes to `TextInput` are announced in the changelog [1], including three that are breaking, but I haven't been able to identify any in particular that would start giving us that error. With that dealt with, we also get this new error on calling various methods on the instance stored at a `TextInput` ref (e.g., `textInputRef.current.focus()`): ``` Cannot call textInputRef.current.focus because: • Either property focus is missing in AbstractComponent [1]. • Or property focus is missing in object type [2]. ``` At first, I thought something was wrong with how we're annotating the variable storing the ref, or that Flow didn't fully understand the `React.createRef` API (we started using that in a recent commit before the main upgrade commit). But rather, it seems to be an issue that's known to occur at RN v0.61.1, and which didn't occur on `master` as of 2020-04-06 [2]. Checking commits around that date in `react-native`, I'm pretty sure we'll have a fix in RN v0.63 (zulip#4245). [1] https://github.com/react-native-community/releases/blob/master/CHANGELOG.md#0620 [2] See point 2 at facebook/react-native#28459 (comment).

The Flow bug in question is facebook/flow#8178; it's reportedly fixed in Flow v0.115; we'll get v0.122 with RN v0.63 (zulip#4245).

We add `typeof` in several places to address this Flow error that starts appearing at the RN and Flow upgrade: ``` Cannot use `TextInput` as a type. A name can be used as a type only if it refers to a type definition, an interface definition, or a class definition. To get the type of a non-class value, use `typeof`. ``` I'm not sure if this is due to the Flow upgrade or to changes React Native made to `TextInput`, or both. Several changes to `TextInput` are announced in the RN changelog [1], including three that are breaking, but I haven't been able to identify any in particular that would start giving us that error. With that dealt with, we also get this new error on calling various methods on the instance stored at a `TextInput` ref (e.g., `textInputRef.current.focus()`): ``` Cannot call textInputRef.current.focus because: • Either property focus is missing in AbstractComponent [1]. • Or property focus is missing in object type [2]. ``` At first, I thought something was wrong with how we're annotating the variable storing the ref, or that Flow didn't fully understand the `React.createRef` API (we started using that in a recent commit before the main upgrade commit). But rather, it seems to be an issue that's known to occur at RN v0.61.1, and which didn't occur on `master` as of 2020-04-06 [2]. Checking commits around that date in `react-native`, I'm pretty sure we'll have a fix in RN v0.63 (zulip#4245). [1] https://github.com/react-native-community/releases/blob/master/CHANGELOG.md#0620 [2] See point 2 at facebook/react-native#28459 (comment).

The Flow bug in question is facebook/flow#8178; it's reportedly fixed in Flow v0.115; we'll get v0.122 with RN v0.63 (zulip#4245).

We add `typeof` in several places to address this Flow error that starts appearing at the RN and Flow upgrade: ``` Cannot use `TextInput` as a type. A name can be used as a type only if it refers to a type definition, an interface definition, or a class definition. To get the type of a non-class value, use `typeof`. ``` I'm not sure if this is due to the Flow upgrade or to changes React Native made to `TextInput`, or both. Several changes to `TextInput` are announced in the RN changelog [1], including three that are breaking, but I haven't been able to identify any in particular that would start giving us that error. With that dealt with, we also get this new error on calling various methods on the instance stored at a `TextInput` ref (e.g., `textInputRef.current.focus()`): ``` Cannot call textInputRef.current.focus because: • Either property focus is missing in AbstractComponent [1]. • Or property focus is missing in object type [2]. ``` At first, I thought something was wrong with how we're annotating the variable storing the ref, or that Flow didn't fully understand the `React.createRef` API (we started using that in a recent commit before the main upgrade commit). But rather, it seems to be an issue that's known to occur at RN v0.61.1, and which didn't occur on `master` as of 2020-04-06 [2]. Checking commits around that date in `react-native`, I'm pretty sure we'll have a fix in RN v0.63 (zulip#4245). [1] https://github.com/react-native-community/releases/blob/master/CHANGELOG.md#0620 [2] See point 2 at facebook/react-native#28459 (comment).

The Flow bug in question is facebook/flow#8178; it's reportedly fixed in Flow v0.115; we'll get v0.122 with RN v0.63 (zulip#4245).

We add `typeof` in several places to address this Flow error that starts appearing at the RN and Flow upgrade: ``` Cannot use `TextInput` as a type. A name can be used as a type only if it refers to a type definition, an interface definition, or a class definition. To get the type of a non-class value, use `typeof`. ``` I'm not sure if this is due to the Flow upgrade or to changes React Native made to `TextInput`, or both. Several changes to `TextInput` are announced in the RN changelog [1], including three that are breaking, but I haven't been able to identify any in particular that would start giving us that error. With that dealt with, we also get this new error on calling various methods on the instance stored at a `TextInput` ref (e.g., `textInputRef.current.focus()`): ``` Cannot call textInputRef.current.focus because: • Either property focus is missing in AbstractComponent [1]. • Or property focus is missing in object type [2]. ``` At first, I thought something was wrong with how we're annotating the variable storing the ref, or that Flow didn't fully understand the `React.createRef` API (we started using that in a recent commit before the main upgrade commit). But rather, it seems to be an issue that's known to occur at RN v0.61.1, and which didn't occur on `master` as of 2020-04-06 [2]. Checking commits around that date in `react-native`, I'm pretty sure we'll have a fix in RN v0.63 (zulip#4245). [1] https://github.com/react-native-community/releases/blob/master/CHANGELOG.md#0620 [2] See point 2 at facebook/react-native#28459 (comment).

The Flow bug in question is facebook/flow#8178; it's reportedly fixed in Flow v0.115; we'll get v0.122 with RN v0.63 (zulip#4245).

We add `typeof` in several places to address this Flow error that starts appearing at the RN and Flow upgrade: ``` Cannot use `TextInput` as a type. A name can be used as a type only if it refers to a type definition, an interface definition, or a class definition. To get the type of a non-class value, use `typeof`. ``` I'm not sure if this is due to the Flow upgrade or to changes React Native made to `TextInput`, or both. Several changes to `TextInput` are announced in the RN changelog [1], including three that are breaking, but I haven't been able to identify any in particular that would start giving us that error. With that dealt with, we also get this new error on calling various methods on the instance stored at a `TextInput` ref (e.g., `textInputRef.current.focus()`): ``` Cannot call textInputRef.current.focus because: • Either property focus is missing in AbstractComponent [1]. • Or property focus is missing in object type [2]. ``` At first, I thought something was wrong with how we're annotating the variable storing the ref, or that Flow didn't fully understand the `React.createRef` API (we started using that in a recent commit before the main upgrade commit). But rather, it seems to be an issue that's known to occur at RN v0.61.1, and which didn't occur on `master` as of 2020-04-06 [2]. Checking commits around that date in `react-native`, I'm pretty sure we'll have a fix in RN v0.63 (zulip#4245). [1] https://github.com/react-native-community/releases/blob/master/CHANGELOG.md#0620 [2] See point 2 at facebook/react-native#28459 (comment).

chrisbobbe · 2020-09-18T21:58:51Z

In RN v0.62, we started getting (and suppressing) this new error on calling various methods on a TextInput stored in a ref (e.g.,textInputRef.current.focus()):

Cannot call textInputRef.current.focus because:
 • Either property focus is missing in AbstractComponent [1].
 • Or property focus is missing in object type [2].

At first, I thought something was wrong with how we're annotating the variable storing the ref, or that Flow didn't fully understand the React.createRef API, which we started using in more places just before the RN v0.62 upgrade. Rather, it seems to be a known issue that wasn't observed on React Native's master as of 2020-04-06 [2]. Checking commits around that date, I'm pretty sure we'll have a fix in RN v0.63 (#4245).

The issue is described in point 2 of facebook/react-native#28459 (comment).

The Flow bug in question is facebook/flow#8178; it's reportedly fixed in Flow v0.115; we'll get v0.122 with RN v0.63 (zulip#4245).

We add `typeof` in several places to address this Flow error that starts appearing at the RN and Flow upgrade: ``` Cannot use `TextInput` as a type. A name can be used as a type only if it refers to a type definition, an interface definition, or a class definition. To get the type of a non-class value, use `typeof`. ``` I'm not sure if this is due to the Flow upgrade or to changes React Native made to `TextInput`, or both. Several changes to `TextInput` are announced in the RN changelog [1], including three that are breaking, but I haven't been able to identify any in particular that would start giving us that error. With that dealt with, we also get this new error on calling various methods on the instance stored at a `TextInput` ref (e.g., `textInputRef.current.focus()`): ``` Cannot call textInputRef.current.focus because: • Either property focus is missing in AbstractComponent [1]. • Or property focus is missing in object type [2]. ``` At first, I thought something was wrong with how we're annotating the variable storing the ref, or that Flow didn't fully understand the `React.createRef` API (we started using that in a recent commit before the main upgrade commit). But rather, it seems to be an issue that's known to occur at RN v0.61.1, and which didn't occur on `master` as of 2020-04-06 [2]. Checking commits around that date in `react-native`, I'm pretty sure we'll have a fix in RN v0.63 (zulip#4245). I posted at the RN v0.63 upgrade issue (zulip#4245) with these observations [3]. [1] https://github.com/react-native-community/releases/blob/master/CHANGELOG.md#0620 [2] See point 2 at facebook/react-native#28459 (comment). [3] zulip#4245 (comment)

The Flow bug in question is facebook/flow#8178; it's reportedly fixed in Flow v0.115; we'll get v0.122 with RN v0.63 (zulip#4245).

We add `typeof` in several places to address this Flow error that starts appearing at the RN and Flow upgrade: ``` Cannot use `TextInput` as a type. A name can be used as a type only if it refers to a type definition, an interface definition, or a class definition. To get the type of a non-class value, use `typeof`. ``` I'm not sure if this is due to the Flow upgrade or to changes React Native made to `TextInput`, or both. Several changes to `TextInput` are announced in the RN changelog [1], including three that are breaking, but I haven't been able to identify any in particular that would start giving us that error. With that dealt with, we also get this new error on calling various methods on the instance stored at a `TextInput` ref (e.g., `textInputRef.current.focus()`): ``` Cannot call textInputRef.current.focus because: • Either property focus is missing in AbstractComponent [1]. • Or property focus is missing in object type [2]. ``` At first, I thought something was wrong with how we're annotating the variable storing the ref, or that Flow didn't fully understand the `React.createRef` API (we started using that in a recent commit before the main upgrade commit). But rather, it seems to be an issue that's known to occur at RN v0.61.1, and which didn't occur on `master` as of 2020-04-06 [2]. Checking commits around that date in `react-native`, I'm pretty sure we'll have a fix in RN v0.63 (zulip#4245). I posted at the RN v0.63 upgrade issue (zulip#4245) with these observations [3]. [1] https://github.com/react-native-community/releases/blob/master/CHANGELOG.md#0620 [2] See point 2 at facebook/react-native#28459 (comment). [3] zulip#4245 (comment)

chrisbobbe · 2020-11-20T01:11:51Z

With facebook/react-native@232517a (released in RN v0.63) we can get sub-millisecond resolution when timing things for performance; see discussion.

Fixing these will end up saving us from over 300 Flow errors when it's time to upgrade Flow to 0.122.0, which we'll do with the React Native v0.63 upgrade (zulip#4245). Yay!

…le`. Partly in the spirit of 8b30fa9, but also because this helps us avoid a mystifying error reported by Flow when we take the upgrade to Flow v0.122.0, with the React Native v0.63 upgrade (zulip#4245). I was seeing the error on the use of `ZulipButton` in `AuthScreen`; it didn't like what I was passing for the `style` prop. When I temporarily commented out the `style` prop passed to `IosCompliantAppleAuthButton`, the error disappeared. It doesn't make a lot of sense to me, but it sounds like `IosCompliantAppleAuthButton`'s type for its `style` prop was influencing what type `styles.halfMarginTop` was inferred to have, when it was passed to `ZulipButton`.

Fixing these will end up saving us from quite a lot of Flow errors when it's time to upgrade Flow to 0.122.0, which we'll do with the React Native v0.63 upgrade (zulip#4245). Yay!

…le`. Partly in the spirit of 8b30fa9, but also because this helps us avoid a mystifying error reported by Flow when we take the upgrade to Flow v0.122.0, with the React Native v0.63 upgrade (zulip#4245). I was seeing the error on the use of `ZulipButton` in `AuthScreen`; it didn't like what I was passing for the `style` prop. When I temporarily commented out the `style` prop passed to `IosCompliantAppleAuthButton`, the error disappeared. It doesn't make a lot of sense to me, but it sounds like `IosCompliantAppleAuthButton`'s type for its `style` prop was influencing what type `styles.halfMarginTop` was inferred to have, when it was passed to `ZulipButton`.

Fixing these will end up saving us from quite a lot of Flow errors when it's time to upgrade Flow to 0.122.0, which we'll do with the React Native v0.63 upgrade (zulip#4245). Yay!

…le`. Partly in the spirit of 8b30fa9, but also because this helps us avoid lots of mystifying error reports from Flow when we take the upgrade to Flow v0.122.0, with the React Native v0.63 upgrade (zulip#4245). See discussion of those errors [1], and Greg's conclusion that Flow might have been a bit more helpful than it was here. Ah, well. [1] https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/Flow.20errors.20in.20.23M4318/near/1075420

chrisbobbe · 2021-01-01T01:51:25Z

Another reason for getting this upgrade has been discovered—using RN v63.2 will reportedly fix #4365! Marking as high priority.

Much of the work has already been done, but the new Flow version that we'll take along with it has lots of issues with our use of react-navigation, so I've been hoping to finish #4296 (for which #4300 is open) before taking up the RN upgrade again.

chrisbobbe · 2021-01-04T16:07:44Z

~~For cross-reference: #4320 and #4321 are currently open.~~ Done!

gnprice · 2021-01-14T03:31:50Z

And now #4296 is complete too!

With the new Flow version (0.122.0) coming along with the React Native v0.63 upgrade (zulip#4245), this would be flagged with a "Could not decide which case to select" error. I'm not sure why it has trouble distinguishing this array of strings from a possible array of numbers, but it's simple enough to just annotate it as an array of strings, so, might as well.

Despite passing `undefined` as the `defaultValue` argument to `React.createContext`, consumers will never see `undefined` as the value for `this.context` or `useContext(TranslationContext)`. That is, as long as `TranslationContext.Provider` is above such consumers in the component hierarchy. From React's doc on `createContext` [1], """ The `defaultValue` argument is **only** used when a component does not have a matching Provider above it in the tree. This can be helpful for testing components in isolation without wrapping them. """ Adding this annotation will satisfy the new version of Flow (0.122.0) that we'll get along with the React Native v0.63 upgrade (zulip#4245) soon. [1] https://reactjs.org/docs/context.html#reactcreatecontext

With the new Flow version (0.122.0) coming along with the React Native v0.63 upgrade (zulip#4245), this would be flagged with a "Could not decide which case to select" error. I'm not sure why it has trouble distinguishing this array of strings from a possible array of numbers, but it's simple enough to just annotate it as an array of strings, so, might as well.

Despite passing `undefined` as the `defaultValue` argument to `React.createContext`, consumers will never see `undefined` as the value for `this.context` or `useContext(TranslationContext)`. That is, as long as `TranslationContext.Provider` is above such consumers in the component hierarchy. From React's doc on `createContext` [1], """ The `defaultValue` argument is **only** used when a component does not have a matching Provider above it in the tree. This can be helpful for testing components in isolation without wrapping them. """ Adding this annotation will satisfy the new version of Flow (0.122.0) that we'll get along with the React Native v0.63 upgrade (zulip#4245) soon. [1] https://reactjs.org/docs/context.html#reactcreatecontext

In this commit: - Update "react-native", "react", and "flow-bin" in package.json. Run `pod update Folly --no-repo-update` to move past an error on the `pod install` step of the `postinstall` script [1]. After this step, the Podfile.lock file is much changed, as expected. There is also a change in the project.pbxproj file. - Update .flowconfig with the new Flow version, and address one new warning by removing a `$FlowFixMe` that we shouldn't have needed in the first place. (Usually this part is much more complicated!) - Update "jest-expo" in package.json, to oblige a peer-dependency constraint on "react". - TODO: Do something about react-native-cameraroll. - Make a change to the Podfile, according to facebook/react-native@a35efb940. - Instead of spelling out all the Pods from RN (all the non-Flipper-related Pods, that is -- we'll handle the Flipper ones in a later commit), call a function defined by React Native, `use_react_native!`, newly exposed in RN v0.63. - Since we're still using React-RCTPushNotification (pending the resolution of zulip#4163), take care to keep React-RCTPushNotification. It apparently hasn't yet been removed from React Native, but it understandably isn't handled by `use_react_native!`. See the PR thread for the list of RN commits affecting the template app and how we've chosen to propagate the template-app changes into our project. See also the RN v0.62 -> v0.63 upgrade guide [2], which gives a visual representation of the changes to the template app. It mostly matches the changes we've made; important deviations should have been explained in the commit list in the PR thread [3]. [1] TODO: Link to explanation on PR. [2] https://react-native-community.github.io/upgrade-helper/?from=0.62.2&to=0.63.4 [3] As always, the guide does show some changes that don't appear in the template app. I think this noise is an effect of how the guide is generated (with react-native-community/rn-diff-purge) and can safely be ignored. It's a diff between a fresh app created with `react-native init --version=$CURRENT` and a fresh app created with `react-native init --version=$NEXT`, for the selected values of `$CURRENT` and `$NEXT`. In particular: - I believe that some dependency version range changes in package.json, including for @babel/core and @babel/runtime, might be caused by different versions for those dependencies being available when the `react-native init` commands are run. - Some changes in ordering and unique ID values always seem to show up in the project.pbxproj file. Fixes: zulip#4245

In this commit: - Update "react-native", "react", and "flow-bin" in package.json. Run `pod update Folly --no-repo-update` to move past an error on the `pod install` step of the `postinstall` script [1]. After this step, the Podfile.lock file is much changed, as expected. There is also a change in the project.pbxproj file. - Update .flowconfig with the new Flow version, and address one new warning by removing a `$FlowFixMe` that we shouldn't have needed in the first place. (Usually this part is much more complicated!) - Update "jest-expo" in package.json, to oblige a peer-dependency constraint on "react". - TODO: Do something about react-native-cameraroll. - Make a change to the Podfile, according to facebook/react-native@a35efb940. - Instead of spelling out all the Pods from RN (all the non-Flipper-related Pods, that is -- we'll handle the Flipper ones in a later commit), call a function defined by React Native, `use_react_native!`, newly exposed in RN v0.63. - Since we're still using React-RCTPushNotification (pending the resolution of zulip#4163), take care to keep React-RCTPushNotification. It apparently hasn't yet been removed from React Native, but it understandably isn't handled by `use_react_native!`. See the PR thread [2] for the list of RN commits affecting the template app and how we've chosen to propagate the template-app changes into our project. See also the RN v0.62 -> v0.63 upgrade guide [3], which gives a visual representation of the changes to the template app. It mostly matches the changes we've made; important deviations should have been explained in the commit list in the PR thread [4]. [1] See zulip#4420 (comment) for more details on this. [2] zulip#4420 (comment) [3] https://react-native-community.github.io/upgrade-helper/?from=0.62.2&to=0.63.4 [4] As always, the guide does show some changes that don't appear in the template app. I think this noise is an effect of how the guide is generated (with react-native-community/rn-diff-purge) and can safely be ignored. It's a diff between a fresh app created with `react-native init --version=$CURRENT` and a fresh app created with `react-native init --version=$NEXT`, for the selected values of `$CURRENT` and `$NEXT`. In particular: - I believe that some dependency version range changes in package.json, including for @babel/core and @babel/runtime, might be caused by different versions for those dependencies being available when the `react-native init` commands are run. - Some changes in ordering and unique ID values always seem to show up in the project.pbxproj file. Fixes: zulip#4245

In this commit: - Update "react-native", "react", and "flow-bin" in package.json. Run `pod update Folly --no-repo-update` to move past an error on the `pod install` step of the `postinstall` script [1]. After this step, the Podfile.lock file is much changed, as expected. There is also a change in the project.pbxproj file. - Update .flowconfig with the new Flow version, and address one new warning by removing a `$FlowFixMe` that we shouldn't have needed in the first place. (Usually this part is much more complicated!) - Update "jest-expo" in package.json, to oblige a peer-dependency constraint on "react". - Make a change to the Podfile, according to facebook/react-native@a35efb940. - Instead of spelling out all the Pods from RN (all the non-Flipper-related Pods, that is -- we'll handle the Flipper ones in a later commit), call a function defined by React Native, `use_react_native!`, newly exposed in RN v0.63. - Since we're still using React-RCTPushNotification (pending the resolution of zulip#4163), take care to keep React-RCTPushNotification. It apparently hasn't yet been removed from React Native, but it understandably isn't handled by `use_react_native!`. See the PR thread [2] for the list of RN commits affecting the template app and how we've chosen to propagate the template-app changes into our project. See also the RN v0.62 -> v0.63 upgrade guide [3], which gives a visual representation of the changes to the template app. It mostly matches the changes we've made; important deviations should have been explained in the commit list in the PR thread [4]. We know of one bug that's directly solved by taking this upgrade: issue zulip#4365. I've just tested, and I do indeed start to see avatars on a simulator running iOS 14, where I didn't see them before. [1] See zulip#4420 (comment) for more details on this. [2] zulip#4420 (comment) [3] https://react-native-community.github.io/upgrade-helper/?from=0.62.2&to=0.63.4 [4] As always, the guide does show some changes that don't appear in the template app. I think this noise is an effect of how the guide is generated (with react-native-community/rn-diff-purge) and can safely be ignored. It's a diff between a fresh app created with `react-native init --version=$CURRENT` and a fresh app created with `react-native init --version=$NEXT`, for the selected values of `$CURRENT` and `$NEXT`. In particular: - I believe that some dependency version range changes in package.json, including for @babel/core and @babel/runtime, might be caused by different versions for those dependencies being available when the `react-native init` commands are run. - Some changes in ordering and unique ID values always seem to show up in the project.pbxproj file. Fixes: zulip#4245 Fixes: zulip#4365

With the new Flow version (0.122.0) coming along with the React Native v0.63 upgrade (zulip#4245), this would be flagged with a "Could not decide which case to select" error. I'm not sure why it has trouble distinguishing this array of strings from a possible array of numbers, but it's simple enough to just annotate it as an array of strings, so, might as well.

Despite passing `undefined` as the `defaultValue` argument to `React.createContext`, consumers will never see `undefined` as the value for `this.context` or `useContext(TranslationContext)`. That is, as long as `TranslationContext.Provider` is above such consumers in the component hierarchy. From React's doc on `createContext` [1], """ The `defaultValue` argument is **only** used when a component does not have a matching Provider above it in the tree. This can be helpful for testing components in isolation without wrapping them. """ Adding this annotation will satisfy the new version of Flow (0.122.0) that we'll get along with the React Native v0.63 upgrade (zulip#4245) soon. [1] https://reactjs.org/docs/context.html#reactcreatecontext

In this commit: - Update "react-native", "react", and "flow-bin" in package.json. Run `pod update Folly --no-repo-update` to move past an error on the `pod install` step of the `postinstall` script [1]. After this step, the Podfile.lock file is much changed, as expected. There is also a change in the project.pbxproj file. - Update .flowconfig with the new Flow version, and address one new warning by removing a `$FlowFixMe` that we shouldn't have needed in the first place. (Usually this part is much more complicated!) - Update "jest-expo" in package.json, to oblige a peer-dependency constraint on "react". - Make a change to the Podfile, according to facebook/react-native@a35efb940. - Instead of spelling out all the Pods from RN (all the non-Flipper-related Pods, that is -- we'll handle the Flipper ones in a later commit), call a function defined by React Native, `use_react_native!`, newly exposed in RN v0.63. - Since we're still using React-RCTPushNotification (pending the resolution of zulip#4163), take care to keep React-RCTPushNotification. It apparently hasn't yet been removed from React Native, but it understandably isn't handled by `use_react_native!`. See the PR thread [2] for the list of RN commits affecting the template app and how we've chosen to propagate the template-app changes into our project. See also the RN v0.62 -> v0.63 upgrade guide [3], which gives a visual representation of the changes to the template app. It mostly matches the changes we've made; important deviations should have been explained in the commit list in the PR thread [4]. We know of one bug that's directly solved by taking this upgrade: issue zulip#4365. I've just tested, and I do indeed start to see avatars on a simulator running iOS 14, where I didn't see them before. [1] See zulip#4420 (comment) for more details on this. [2] zulip#4420 (comment) [3] https://react-native-community.github.io/upgrade-helper/?from=0.62.2&to=0.63.4 [4] As always, the guide does show some changes that don't appear in the template app. I think this noise is an effect of how the guide is generated (with react-native-community/rn-diff-purge) and can safely be ignored. It's a diff between a fresh app created with `react-native init --version=$CURRENT` and a fresh app created with `react-native init --version=$NEXT`, for the selected values of `$CURRENT` and `$NEXT`. In particular: - I believe that some dependency version range changes in package.json, including for @babel/core and @babel/runtime, might be caused by different versions for those dependencies being available when the `react-native init` commands are run. - Some changes in ordering and unique ID values always seem to show up in the project.pbxproj file. Fixes: zulip#4245 Fixes: zulip#4365

chrisbobbe added upstream: RN Issues related to an issue in React Native blocked on other work To come back to after another related PR, or some other task. labels Sep 2, 2020

chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this issue Sep 9, 2020

message, presence types: Add some fixmes.

c1d209a

The Flow bug in question is facebook/flow#8178; it's reportedly fixed in Flow v0.115; we'll get v0.122 with RN v0.63 (zulip#4245).

chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this issue Sep 11, 2020

message, presence types: Add some fixmes.

87ddf43

The Flow bug in question is facebook/flow#8178; it's reportedly fixed in Flow v0.115; we'll get v0.122 with RN v0.63 (zulip#4245).

chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this issue Sep 17, 2020

message, presence types: Add some fixmes.

887cd4b

The Flow bug in question is facebook/flow#8178; it's reportedly fixed in Flow v0.115; we'll get v0.122 with RN v0.63 (zulip#4245).

chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this issue Sep 17, 2020

message, presence types: Add some fixmes.

863981c

The Flow bug in question is facebook/flow#8178; it's reportedly fixed in Flow v0.115; we'll get v0.122 with RN v0.63 (zulip#4245).

gnprice mentioned this issue Sep 18, 2020

RN v0.61 -> v0.62 upgrade #4247

Merged

chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this issue Sep 18, 2020

message, presence types: Add some fixmes.

50cb396

The Flow bug in question is facebook/flow#8178; it's reportedly fixed in Flow v0.115; we'll get v0.122 with RN v0.63 (zulip#4245).

gnprice pushed a commit to chrisbobbe/zulip-mobile that referenced this issue Sep 18, 2020

message, presence types: Add some fixmes.

e020dec

The Flow bug in question is facebook/flow#8178; it's reportedly fixed in Flow v0.115; we'll get v0.122 with RN v0.63 (zulip#4245).

chrisbobbe removed the blocked on other work To come back to after another related PR, or some other task. label Sep 23, 2020

chrisbobbe mentioned this issue Dec 1, 2020

Follow some of RN's Flipper changes before taking RN v0.63 upgrade. #4322

Merged

titanous mentioned this issue Jan 1, 2021

Avatars don't work on iOS 14, except in message list #4365

Closed

chrisbobbe self-assigned this Jan 1, 2021

chrisbobbe added the P1 high-priority label Jan 1, 2021

chrisbobbe mentioned this issue Jan 14, 2021

Anticipate and fix a few Flow errors we'd get with RN v0.63 and Flow 0.122. #4414

Merged

chrisbobbe mentioned this issue Jan 20, 2021

Upgrade to React Native v63. #4420

Merged

gnprice closed this as completed in bcc1356 Jan 22, 2021

gnprice closed this as completed in #4420 Jan 22, 2021

gnprice mentioned this issue Jan 22, 2021

Upgrade to RN v0.64 #4426

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Upgrade to RN v0.63 #4245

Upgrade to RN v0.63 #4245

chrisbobbe commented Sep 2, 2020 •

edited

chrisbobbe commented Sep 2, 2020

chrisbobbe commented Sep 18, 2020

chrisbobbe commented Nov 20, 2020

chrisbobbe commented Jan 1, 2021 •

edited

chrisbobbe commented Jan 4, 2021 •

edited

gnprice commented Jan 14, 2021

Upgrade to RN v0.63 #4245

Upgrade to RN v0.63 #4245

Comments

chrisbobbe commented Sep 2, 2020 • edited

chrisbobbe commented Sep 2, 2020

chrisbobbe commented Sep 18, 2020

chrisbobbe commented Nov 20, 2020

chrisbobbe commented Jan 1, 2021 • edited

chrisbobbe commented Jan 4, 2021 • edited

gnprice commented Jan 14, 2021

chrisbobbe commented Sep 2, 2020 •

edited

chrisbobbe commented Jan 1, 2021 •

edited

chrisbobbe commented Jan 4, 2021 •

edited