👀 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.
When we upgrade to a version of @segment/analytics-react-native that includes an updated kotlin version compatible with the version of kotlin we need for React Native.
When updating to rn-0.69.10 we had to patch this due to kotlin version missmatch.
When we upgrade our deps to a version of react-native that includes removal of deprecated PropTypes.
When updating to rn-0.69.10 we had to patch this due to deprecation of PropTypes. For this reason we also installed deprecated-react-native-prop-types to avoid errors and we patched the react-native package to use the deprecated PropTypes coming from the deprecated-react-native-prop-types package.
When we upgrade react-native to 75 according to this facebook/react-native#41907 (comment) & https://github.com/facebook/react-native/pull/43497/files#diff-feb65a029adc6c226f7d3bfdc5238d2c8f31c4da1fea238705b2012f35178af6
When updating to rn-0.73.9 we had to patch this due to some changes on the setup jest files making our tests fail due to a missconfiguration on the image jest setup.
When we upgrade our deps to a version of react-native that includes removal of deprecated PropTypes.
When updating to rn-0.69.10 we had to patch this due to deprecation of PropTypes. For this reason we also installed deprecated-react-native-prop-types to avoid errors and we patched the react-native package to use the deprecated PropTypes coming from the deprecated-react-native-prop-types package.
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.
When react-native-mapbox adds the events framework as dependency, tried removed in 8.4.0 and was getting a crash on startup do to missing framework.
We had issues with our archive becoming invalid and failing to export when we updated mapbox and cocoapods
- mapbox released a beta version that fixed the issue for our setup
- See issues here: CocoaPods/CocoaPods#10385, https://github.com/react-native-mapbox-gl/maps/issues/1097
When react-native-mapbox/maps fixes the type issue here.
Typescript complains about some invalid type definitions for generic values. Next time we update mapbox we should try removing the patch, run yarn type-check and if it succeeds you can get rid of the patch.
We should try removing it next time we update our mapbox dependencies (at time of writing 8.4.0). If you remove the plist value and open a map (City guide) and don't see a warning about falling back to a local rasterization you should be good to go.
There is an issue here that explains the issue and suggests setting explicity in plist: mapbox/mapbox-gl-native-ios#589
Not really needed to be removed, unless it causes problems.
We use this type in out code for our tests and the resolveMostRecentRelayOperation, so we exported it.
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 heirarchy. The delay is a workaround.
react-navigation has a bug with nested independent NavigationContainer instances. react-navigation/react-navigation#8611
Our patch alleviates the issue in our case, but would not work as an upstream PR.
To remove this hack we can do one of two things:
- Stop using nested navigation containers.
- Fix
@react-navigation/coreproperly upstream.
We can remove these hacks when they don't matter anymore. Neither are likely to be fixed by facebook.
There are two hacks here:
- We hack the output of the compiler to provide clickable links for error messages. Relay assumes that you put your
__generated__folder in the root of your project, but we put it insrc. - We make sure that files which do not change are not overwritten. This prevents excessive reloading by metro.
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).
Once we have removed the palette directory from eigen.
Look at the tech plan here: https://www.notion.so/artsy/palette-mobile-in-eigen-c5e3396302734f0a921aed3978f5dbeb
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 @braze/react-native-sdk to version >= 8.3.0.
We had to patch Braze in order to proceed with the react native upgrade to 0.73.9. The patch was needed to support kotlin jvm target 17 and in order to also make targetCompatibility and sourceCompatibility compatible with the JAVA 17 which is the standard for newer rn versions starting 0.73.
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 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 this pr is released in a new version of react-native-gesture-handler and we upgrade to it: software-mansion/react-native-gesture-handler#3149
We want to be able to open the swipeable view using the openRight function, but it doesn't seem to be working as expected. This patch is a workaround to make it work.