👀 See comment on top of file for template.
Maybe sometime end of 2020, we can change the file EchoNew.json back to Echo.json.
There was a case where echo returns 401 when a user asks for the latest echo options. This might be caused by some key misconfiguration, or it might not. Right now we have figured out that the app was storing broken Echo.json when the status was 401, and this caused the app to crash. As the simplest way to get around that we decided to rename the file, so in the next app update we would force all users to grab a new echo json file (this time named EchoNew.json). We have also added code to make sure we don't store broken echo json files locally anymore.
After a few months we should be safe to return to the old name if we want. If we decide to do that, we should make sure to remove the old file that might have been sitting on users' phones.
Doesn't really need to be removed but can be if view hierarchy issue is fixed in RN or our LoadingModal see PR for more details: #4283
We have a modal for showing a loading state and a onDismiss call that optionally displays an alert message, on iOS 14 we came across an issue where the alert was not displaying because when onDismiss was called the LoadingModal was still in the view hierarchy. The delay is a workaround.
Once facebook/react-native#29664 is merged or facebook/react-native#29663 solved.
As you can see in the PR and issue, android doesn't use ellipsis on the placeholder of a TextInput. That makes for a funky cut-off.
We added a workaround on Input, to accept an array of placeholders, from longest to shortest, so that android can measure which one fits in the TextInput as placeholder, and it uses that. When android can handle a long placeholder and use ellipsis or if we don't use long placeholders anymore, this can go.
Once we want to use react-native-push-notification on iOS
This is happening because react-native-push-notification requires @react-native-community/push-notification-ios. We are not adding this dependency at this time because it is unnecessary and we do not use react-native-push-notification on iOS. Also, we do not want unnecessary conflicts between our native push notification implementation and @react-native-community/push-notification-ios's.
Once we no longer use our native implementation of pushView on iOS
We cannot pass functions as props because navigate.ts on ios uses the native obj-c definition of pushView in ARScreenPresenterModule.m.
React native is not able to convert js functions so this is passed as null to the underlying native method
See what can be converted: https://github.com/facebook/react-native/blob/main/React/Base/RCTConvert.h
PropsStore allows us to temporarily hold on the props and reinject them back into the destination view or module.
Once we remove ORStackView or the upstream repo adds the import. May want to proactively open a PR for this.
The Pod does not compile when imported as is without hack due to missing symbols from UIKit.
We should see if it is still necessary when we remove the old native navigation on iOS. To check: go into City Guide, leave, enter again and then try to change the city. If it works without this code it can be removed. If it is still an issue with old native navigation gone this can either be removed when we remove or rebuild City Guide or if we change how props are saved in PageWrapper.
City Guide is a mixture of native components and react components, prop updates from the native side are not updating the component on the react native side without this manual check and update. See the PR here for the change in the AppRegistry: #6348
React-Native-Image-Crop-Picker App restarting when photo is taken. Fix is in ArtsyNativeModule.clearCache.
When we fix the actual issue. https://artsyproduct.atlassian.net/browse/MOPLAT-196
The app restarts when the user takes a picture to pass to react-native-image-crop-picker (ivpusic/react-native-image-crop-picker#1704). We do not know exactly why this is happening. And it seems to happen on random devices, but mostly on android-10 and android-11s. This hack silently clears the cache on android before taking the photo.
To remove this, we need to change our InfiniteScrollArtworksGrid to use a FlatList or any VirtualizedList. We haven't done that yet, because we need the masonry layout. We either need to find a library that gives us masonry layout using a VirtualizedList, or we need to make our own version of this.
Currently our masonry layout (in InfiniteScrollArtworksGrid render()) is using a ScrollView, which is not a VirtualizedList.
Also, currently, the parent that is the FlatList, comes from StickyTabPageFlatList.
Maybe we don't? We can try to remove it at any point, and see if it works. Try with newer cocoapods versions.
This is needed because xcode 14 says that React-Core-AccessibilityResources and some other pods require a development team. We don't really need a dev team for these. Probably some future version of cocoapods will fix this.
Once we can figure out how to mock global.setImmediate with global.setTimeout, preferrably in jest setup file
After upgrading to Jest 29, our use of jest.useFakeTimers() became somewhat funky. In most cases passing legacyFakeTimers: true to the function fixes it, but in other cases it breaks @jest/fake-timers at this line. Not sure why. To elaborate more, when jest runs tests it errors out saying that setImmediate isn't a function (this was removed from Jest 28); however, when trying to mock it with global.setImmediate = global.setTimeout it doesn't work. So ran a patch and replaced it manually in the code, which appears harmless since setImmediate is the same as setTimeout(..., 0).
Just adds a type, so likely doesn't need to be removed. But if they officially add it (see this issue), we could drop this patch.
This package includes a setPageName method on SiftReactNative, but no corresponding type.
I patched it to add the type.
When we upgrade to 6.0.14 or higher, should do shortly but requires fixing a fair few type issues.
React native removed removeEventListener which this library uses and causes jest tests to fail with type errors. This commit fixes the issue: https://github.com/react-navigation/react-navigation/commit/6e9da7304127a7c33cda2da2fa9ea1740ef56604
When this issue is resolved and version 5.0.2 or above is published on Cocoapods. SwiftyJSON/SwiftyJSON#1154
Apples has started requiring apps and certain 3rd party libraries declare in a privacy manifest why they use some apis, SwiftyJSON is one of them. The privacy manifest has been added in 5.0.2 but the version has not been published to cocoapods.
When we stop using flipper or this issue is resolved: invertase/react-native-firebase#6425
The latest versions of react-native-firebase require using static frameworks, and unfortunately this breaks flipper.
https://rnfirebase.io/#altering-cocoapods-to-use-frameworks
The author of react-native-firebase basically said that people should just remove flipper since it is no longer going to be supported by
react native in the future but a bit tough to pull off that bandaid so soon. If flipper does end up supporting this config: 1. remove the entries in the podfile
that have :modular_headers => true and add the static frameworks line from the docs above.
Custom lane google_play_track_rollout_percentages in fastlane dir + associated monkey patches in Fastfile
When this pr is accepted upstream or another way to fetch this data is supported by fastlane: fastlane/fastlane#22029
This info is needed to automate our android rollout but not currently supported by fastlane.
When this pr is accepted upstream or another way to promote historical builds is supported by fastlane: fastlane/fastlane#22025
We want to be able to promote past android builds to prod because we are creating betas often and a release candidate may not be the latest. The developer APIs for google play only return the latest release and fastlane verifies that a release exists before allowing promotion. We added custom logic to work around this.
When react-native-keys merges this PR numandev1/react-native-keys#117
Because RN >= 0.80 has moved react-native from react-native/android to react-native/ReactAndroid, we need to be looking at the new folder instead of the previous one
This patch allows us to animate the appearance of the bottom tabs. This is currently not supported by @react-navigation/bottom-tabs but it's something they do when the user shows/hides the keyboard.
See #12249 for more details.
When Rozenite stable release is published and no longer requires this resolution
This resolution was added to fix Rozenite integration issues. Rozenite was unable to display its dev tools tabs because it couldn't properly detect whether we were using Expo CLI or React Native CLI, causing confusion in its tooling detection logic. The resolution ensures Rozenite can correctly identify our development environment and render its interface properly.
This patch was added to support 16KB page size on Android. It's a copy paste from here software-mansion/react-native-reanimated#7037
It can be removed once we upgrade to any version past 3.17
When we can update the reanimated flatlist CellRendererComponent or it's style, or when this PR gets merged: software-mansion/react-native-reanimated#6573
In the HomeView Tasks, we want to update the FlatList's CellRendererComponent to update the zIndex of the rendered elements so they can be on top of each other, and to animate them we need to use Reanimated's FlatList, but it doesn't support updating the CellRendererComponent prop since they have their own implementation, so we added this patch to update the style of the component in Reanimated's FlatList.
We use a singleton pattern for our ARNotificationsManagerModule, which is also an RCTEventEmitter for things like push notification handling, there is a bug in react native where stopObserving is called when bridge is invalidated but listenerCount is not reset. This causes the module to never start listening again causing events not to be sent over the bridge.
It can be removed once if we stop using the singleton pattern or get rid of ARNotificationsManagerModule, or it is fixed upstream.
This feature flag was added to fix performance issues with scrolling. See https://docs.swmansion.com/react-native-reanimated/docs/guides/performance/#%EF%B8%8F-lower-fps-while-scrolling
We also added a patch to react-native to support this flag and temporarily enabled preventShadowTreeCommitExhaustion and enableCppPropsIteratorSetter flags to fix performance issues.
When reanimated adopts this by default.
This is a bug on the new architecture on Android with this prop and react-native-webview.
When this is merged and we update react-native-webview to a version that contains it: react-native-webview/react-native-webview#3885
The original code had a logging issue where it would log a "cache miss" message immediately after checking the local disk cache, even before checking the remote cache plugin (S3 in our case). This resulted in false-negative messages showing cache misses when the cache was actually available remotely.
The patch:
- Moves the
logger.log(texts.read.miss)call to after the remote plugin check - Fixes the control flow so that the cache miss is only logged if both disk AND remote caches fail
- Improves the conditional logic around remote plugin downloading to properly return the cache path on success
This ensures accurate logging when using remote cache plugins like our S3 build cache implementation.
When the upstream expo-build-disk-cache repository fixes the logging behavior and releases a new version that properly checks remote cache before logging cache misses.
Probably related with this sentry issue https://artsynet.sentry.io/issues/7043718518/events/0e89b1ce77cd4dfe95c45feefea1ed22/ EXC_BAD_ACCESS crash on iOS. This patch is attempting to fix the crash and was found in this reanimated issue (but is a react-native patch): software-mansion/react-native-reanimated#7666 (comment)
When they address this issue on react native main repo
When dominicstop/react-native-ios-context-menu#140 is merged and we upgrade to a version that includes it.
Fatal crash (EIGEN-AZB4) on New Architecture where iOS requests a UITargetedPreview during context menu dismissal but Fabric has already detached the underlying view from the window. The fix guards menuTargetedPreview to return nil when window is nil, letting iOS fall back to a fade-out dismissal instead of crashing.
See: dominicstop/react-native-ios-context-menu#103
Started seeing blank screens on android when app was crashing instead of regularly crashing the app after we enabled new architecture. This patch attempts to fix that.
When the upstream expo-updates repository fixes the issue and releases a new version that properly handles crashes on Android with the new architecture. expo/expo#41543
When @gorhom/bottom-sheet ships a fix for the infinite scrollTo loop on Fabric (New Architecture). Track these upstream issues:
gorhom/react-native-bottom-sheet#2546
gorhom/react-native-bottom-sheet#2547
On Fabric, reanimated's scrollTo uses dispatchCommand which forces a native commit cycle that re-triggers onScroll even when the scroll offset hasn't changed. In useScrollEventsHandlersDefault, when the scrollable state is LOCKED, handleOnScroll calls scrollTo to enforce the lock position, which fires another onScroll, which calls scrollTo again — creating an infinite recursion that crashes with "Maximum call stack size exceeded (native stack depth)".
The patch adds a guard (if (y === lockPosition) return) in handleOnScroll, handleOnEndDrag, and handleOnMomentumEnd to skip the scrollTo call when the scroll position is already at the lock position. It also fixes a bug in handleOnMomentumEnd where scrollableContentOffsetY.value was incorrectly set to 0 instead of lockPosition.
Sentry issue: https://artsynet.sentry.io/issues/7304441200/