Page MenuHomePhabricator
Differential D5918

[native] [24/40] RN 0.70: Update to react-native-reanimated@2.12.0
ClosedPublic
Actions

Authored by ashoat on Dec 18 2022, 7:41 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Apr 5, 1:21 AM
Unknown Object (File)
Thu, Apr 3, 2:24 PM
Unknown Object (File)
Tue, Apr 1, 12:26 AM
Unknown Object (File)
Mon, Mar 31, 5:11 PM
Unknown Object (File)
Sun, Mar 30, 5:32 PM
Unknown Object (File)
Sat, Mar 29, 8:23 AM
Unknown Object (File)
Wed, Mar 26, 1:38 PM
Unknown Object (File)
Wed, Mar 26, 9:46 AM
View All Files
Subscribers
atul

Details

Reviewers
tomek
bartek
Commits
rCOMM72622cf0c4bc: [native] [24/40] RN 0.70: Update to react-native-reanimated@2.12.0
Summary

I was seeing Android build errors with Reanimated, which were resolved after updating.

project.pbxproj change comes from https://github.com/software-mansion/react-native-reanimated/pull/3547

Test Plan
  1. I reviewed the Release Notes and found no breaking changes
  2. Tested along with whole stack: test plan (includes testing Reanimated 1 and 2 animations)

Depends on D5917

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

ashoat created this revision.Dec 18 2022, 7:41 PM
Herald added a subscriber: atul. · View Herald TranscriptDec 18 2022, 7:41 PM
Harbormaster returned this revision to the author for changes because remote builds failed.Dec 18 2022, 7:42 PM
Harbormaster failed remote builds in B14247: Diff 19486!
ashoat retitled this revision from [native] [22/40] RN 0.70: Update to react-native-reanimated@2.12.0 to [native] [23/40] RN 0.70: Update to react-native-reanimated@2.12.0.Dec 18 2022, 7:44 PM
ashoat added a child revision: D5919: [native] [25/40] RN 0.70: Update to react-native-background-upload@6.6.0.Dec 18 2022, 7:44 PM
ashoat retitled this revision from [native] [23/40] RN 0.70: Update to react-native-reanimated@2.12.0 to [native] [24/40] RN 0.70: Update to react-native-reanimated@2.12.0.Dec 18 2022, 8:05 PM
ashoat updated this revision to Diff 19508.Dec 18 2022, 8:19 PM

Rebase

Harbormaster returned this revision to the author for changes because remote builds failed.Dec 18 2022, 8:29 PM
Harbormaster failed remote builds in B14269: Diff 19508!
ashoat updated this revision to Diff 19535.Dec 18 2022, 8:32 PM

Rebase

Harbormaster returned this revision to the author for changes because remote builds failed.Dec 18 2022, 9:03 PM
Harbormaster failed remote builds in B14296: Diff 19535!
ashoat updated this revision to Diff 19597.Dec 19 2022, 8:21 AM

Rebase

ashoat updated this revision to Diff 19630.Dec 19 2022, 8:37 AM

Rebase

Harbormaster failed remote builds in B14348: Diff 19597!Dec 19 2022, 8:43 AM
Harbormaster returned this revision to the author for changes because remote builds failed.Dec 19 2022, 9:10 AM
Harbormaster failed remote builds in B14381: Diff 19630!
ashoat requested review of this revision.Dec 19 2022, 9:11 AM

Please ignore CI until the end of the stack

ashoat updated this revision to Diff 19703.Dec 19 2022, 12:29 PM

Rebase

Harbormaster failed remote builds in B14448: Diff 19703!Dec 19 2022, 12:44 PM
bartek accepted this revision.Dec 20 2022, 3:18 AM
This revision is now accepted and ready to land.Dec 20 2022, 3:18 AM
tomek accepted this revision.Dec 20 2022, 5:18 AM
ashoat updated this revision to Diff 19761.Dec 20 2022, 6:22 AM

Rebase

Harbormaster failed remote builds in B14504: Diff 19761!Dec 20 2022, 6:31 AM
ashoat updated this revision to Diff 19823.Dec 20 2022, 11:02 AM

Rebase

Harbormaster failed remote builds in B14563: Diff 19823!Dec 20 2022, 11:20 AM
This revision was landed with ongoing or failed builds.Dec 20 2022, 12:01 PM
Closed by commit rCOMM72622cf0c4bc: [native] [24/40] RN 0.70: Update to react-native-reanimated@2.12.0 (authored by ashoat). · Explain Why
This revision was automatically updated to reflect the committed changes.
ashoat added a commit: rCOMM72622cf0c4bc: [native] [24/40] RN 0.70: Update to react-native-reanimated@2.12.0.

Revision Contents
Changeset List

PathSize
native/
ios/
Comm.xcodeproj/
4 lines
4 lines
2 lines
8 lines

Diff 19486

View Options

native/ios/Comm.xcodeproj/project.pbxproj

Show First 20 Lines • Show All 396 Lines • ▼ Show 20 Lines async ensureAndroidPushNotifsEnabled() {
let [hasPermission] = permissionPromisesResult; let [hasPermission] = permissionPromisesResult;
const [, canRequestPermission] = permissionPromisesResult; const [, canRequestPermission] = permissionPromisesResult;
if (!hasPermission && canRequestPermission) { if (!hasPermission && canRequestPermission) {
const permissionResponse = await (async () => { const permissionResponse = await (async () => {
// We issue a call to sleep to match iOS behavior where prompt // We issue a call to sleep to match iOS behavior where prompt
// doesn't appear immediately but after logged-out modal disappears // doesn't appear immediately but after logged-out modal disappears
await sleep(10); await sleep(10);
await this.requestAndroidNotificationsPermission(); return await this.requestAndroidNotificationsPermission();
marcinUnsubmitted
Not Done
Inline Actions

We definitely should return something from this lambda since otherwise it is useless to assign it to variable.

When we find we don't have Android notif permissions, we ignore the result of requestAndroidNotificationsPermission. It seems like that would cause us to fail to register notif permissions on Android.

If we find that we don't have permissions then just calling await this.requestAndroidNotificationsPermission(); would result in a prompt asking for notifications permissions. However if the user grants those permissions then hasPermissions is still falsy (since promise returned nothing), so deviceToken will be set to null. Nevertheless permissions are actually granted byt the OS, so the state on the device and keyserver would heal itself on next render.

This differential fixes this case so that if user grants permissions correct state is achieved immediately without need for additional re-render to heal the state.

marcin: We definitely should return something from this lambda since otherwise it is useless to assign…
})(); })();
hasPermission = permissionResponse; hasPermission = permissionResponse;
} }
if (!hasPermission) { if (!hasPermission) {
this.failedToRegisterPushPermissionsAndroid(!canRequestPermission); this.failedToRegisterPushPermissionsAndroid(!canRequestPermission);
return; return;
} }
▲ Show 20 Lines • Show All 328 Lines • Show Last 20 Lines
View Options

native/ios/Podfile.lock

Show First 20 Lines • Show All 396 Lines • ▼ Show 20 Lines async ensureAndroidPushNotifsEnabled() {
let [hasPermission] = permissionPromisesResult; let [hasPermission] = permissionPromisesResult;
const [, canRequestPermission] = permissionPromisesResult; const [, canRequestPermission] = permissionPromisesResult;
if (!hasPermission && canRequestPermission) { if (!hasPermission && canRequestPermission) {
const permissionResponse = await (async () => { const permissionResponse = await (async () => {
// We issue a call to sleep to match iOS behavior where prompt // We issue a call to sleep to match iOS behavior where prompt
// doesn't appear immediately but after logged-out modal disappears // doesn't appear immediately but after logged-out modal disappears
await sleep(10); await sleep(10);
await this.requestAndroidNotificationsPermission(); return await this.requestAndroidNotificationsPermission();
marcinUnsubmitted
Not Done
Inline Actions

We definitely should return something from this lambda since otherwise it is useless to assign it to variable.

When we find we don't have Android notif permissions, we ignore the result of requestAndroidNotificationsPermission. It seems like that would cause us to fail to register notif permissions on Android.

If we find that we don't have permissions then just calling await this.requestAndroidNotificationsPermission(); would result in a prompt asking for notifications permissions. However if the user grants those permissions then hasPermissions is still falsy (since promise returned nothing), so deviceToken will be set to null. Nevertheless permissions are actually granted byt the OS, so the state on the device and keyserver would heal itself on next render.

This differential fixes this case so that if user grants permissions correct state is achieved immediately without need for additional re-render to heal the state.

marcin: We definitely should return something from this lambda since otherwise it is useless to assign…
})(); })();
hasPermission = permissionResponse; hasPermission = permissionResponse;
} }
if (!hasPermission) { if (!hasPermission) {
this.failedToRegisterPushPermissionsAndroid(!canRequestPermission); this.failedToRegisterPushPermissionsAndroid(!canRequestPermission);
return; return;
} }
▲ Show 20 Lines • Show All 328 Lines • Show Last 20 Lines
View Options

native/package.json

Show First 20 Lines • Show All 396 Lines • ▼ Show 20 Lines async ensureAndroidPushNotifsEnabled() {
let [hasPermission] = permissionPromisesResult; let [hasPermission] = permissionPromisesResult;
const [, canRequestPermission] = permissionPromisesResult; const [, canRequestPermission] = permissionPromisesResult;
if (!hasPermission && canRequestPermission) { if (!hasPermission && canRequestPermission) {
const permissionResponse = await (async () => { const permissionResponse = await (async () => {
// We issue a call to sleep to match iOS behavior where prompt // We issue a call to sleep to match iOS behavior where prompt
// doesn't appear immediately but after logged-out modal disappears // doesn't appear immediately but after logged-out modal disappears
await sleep(10); await sleep(10);
await this.requestAndroidNotificationsPermission(); return await this.requestAndroidNotificationsPermission();
marcinUnsubmitted
Not Done
Inline Actions

We definitely should return something from this lambda since otherwise it is useless to assign it to variable.

When we find we don't have Android notif permissions, we ignore the result of requestAndroidNotificationsPermission. It seems like that would cause us to fail to register notif permissions on Android.

If we find that we don't have permissions then just calling await this.requestAndroidNotificationsPermission(); would result in a prompt asking for notifications permissions. However if the user grants those permissions then hasPermissions is still falsy (since promise returned nothing), so deviceToken will be set to null. Nevertheless permissions are actually granted byt the OS, so the state on the device and keyserver would heal itself on next render.

This differential fixes this case so that if user grants permissions correct state is achieved immediately without need for additional re-render to heal the state.

marcin: We definitely should return something from this lambda since otherwise it is useless to assign…
})(); })();
hasPermission = permissionResponse; hasPermission = permissionResponse;
} }
if (!hasPermission) { if (!hasPermission) {
this.failedToRegisterPushPermissionsAndroid(!canRequestPermission); this.failedToRegisterPushPermissionsAndroid(!canRequestPermission);
return; return;
} }
▲ Show 20 Lines • Show All 328 Lines • Show Last 20 Lines
View Options

yarn.lock

Show First 20 Lines • Show All 396 Lines • ▼ Show 20 Lines async ensureAndroidPushNotifsEnabled() {
let [hasPermission] = permissionPromisesResult; let [hasPermission] = permissionPromisesResult;
const [, canRequestPermission] = permissionPromisesResult; const [, canRequestPermission] = permissionPromisesResult;
if (!hasPermission && canRequestPermission) { if (!hasPermission && canRequestPermission) {
const permissionResponse = await (async () => { const permissionResponse = await (async () => {
// We issue a call to sleep to match iOS behavior where prompt // We issue a call to sleep to match iOS behavior where prompt
// doesn't appear immediately but after logged-out modal disappears // doesn't appear immediately but after logged-out modal disappears
await sleep(10); await sleep(10);
await this.requestAndroidNotificationsPermission(); return await this.requestAndroidNotificationsPermission();
marcinUnsubmitted
Not Done
Inline Actions

We definitely should return something from this lambda since otherwise it is useless to assign it to variable.

When we find we don't have Android notif permissions, we ignore the result of requestAndroidNotificationsPermission. It seems like that would cause us to fail to register notif permissions on Android.

If we find that we don't have permissions then just calling await this.requestAndroidNotificationsPermission(); would result in a prompt asking for notifications permissions. However if the user grants those permissions then hasPermissions is still falsy (since promise returned nothing), so deviceToken will be set to null. Nevertheless permissions are actually granted byt the OS, so the state on the device and keyserver would heal itself on next render.

This differential fixes this case so that if user grants permissions correct state is achieved immediately without need for additional re-render to heal the state.

marcin: We definitely should return something from this lambda since otherwise it is useless to assign…
})(); })();
hasPermission = permissionResponse; hasPermission = permissionResponse;
} }
if (!hasPermission) { if (!hasPermission) {
this.failedToRegisterPushPermissionsAndroid(!canRequestPermission); this.failedToRegisterPushPermissionsAndroid(!canRequestPermission);
return; return;
} }
▲ Show 20 Lines • Show All 328 Lines • Show Last 20 Lines