👀 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.
Remove when we stop swizzling UIWindow via ARWindow or react-native-image-crop-picker provides a more robust way of finding the viewController to present on.
ivpusic/react-native-image-crop-picker#1354
We do some swizzling in our AppDelegate that causes [[UIApplication sharedApplication] delegate] window] to return nil, this is used by image-crop-picker to find the currently presented viewController to present the picker onto. This patch looks for our custom window subclass (ARWindow) instead and uses that to find the presented viewController. Note we cannot reliably use the lastWindow rather than checking for our custom subclass because in some circumstances this is not our window but an apple window for example UIInputWindow used for managing the keyboard.
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 software-mansion/react-native-screens#17 is solved or we use another library for screen management.
There is a known issue in react-native-screens that causes the app to crash on restoring from background. The react-native-screens team recommends the following workaround to be added to the MainActivity class on Android software-mansion/react-native-screens#17 (comment).
This has the UX downside of not allowing state restore from background but this is an unsolved problem for RN apps.
When we upgrade styled-components to a version with types that don't complain when we run yarn type-check.
I wasn't the one to add this file, so I don't have all the context, but I do know that styled-component types are missing and/or causing problems when we don't have that file.
The latest change I did was add the ThemeContext in there, because the version of styled-components we use has that, but the types are not exposing that, so I had to manually add it there.
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 the library uses the latest SDWebImage that includes privacy manifests, a version >= 5.19 DylanVann/react-native-fast-image#1031
Apples has started requiring apps and certain 3rd party libraries declare in a privacy manifest why they use some apis. SDWebImage is one of those, SDWebImage has been updated to include a privacy manifest but the wrapper we use, react-native-fast-image, has not. https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api?language=objc
When the library releases this commit https://github.com/muntius/react-native-fast-image/commit/fc2b8acd97f07989e312f5cbd61d2e541fda3611#diff-24ce0837ec34bb03c94a76bc62258a10d1c729e2e6b2f3ac706eab55f76dc0ecR87 and when this issue is closed DylanVann/react-native-fast-image#1002
https://artsynet.sentry.io/issues/4479226101/events/d98fd95bd4c74271a184596c901fac26/ started having some sentry crashes for this reason in iOS 17 and this patch fixes the issue (taken from the main branch of the fast-image repo but not released yet).
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.
After updates to both/either react native react-native-collapsible-tab-view. Remove the patch, reinstall deps and run the app on Android and check if affected components like My Collection render correctly. If they do you can remove the patch.
After upgrading to react native 0.75 screens like my collection using this library stopped rendering on Android. This was fixed with a patch that added some style changes to the components from the package.
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.