👀 See comment on top of file for template.
Remove after enzyme is removed as a dependency.
This is an existing resolution at the creation of HACKS.md. For what I gathered, it is required by enzyme. It requires ~1.0.0, but we need 0.22.0.
We use it in renderToString which takes something like <Image /> and gives us <image />. Using 0.22.0 that works, but when enzyme uses ~1.0.0 it gives <img />, which breaks tests.
Using enzyme we created renderUntil. To replace that, we probably need @testing-library/react or something to replace it. Then we can remove enzyme and cheerio resolution as well.
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.
When this is merged: facebook/react-native#30345.
For some reason CircleCI kept giving an error when running tests TypeError: stacktraceParser.parse is not a function. Once I moved the require higher up, things started working again.
We have a few mapbox related hacks + patches. Grouping here for convenience.
When @react-native-mapbox-gl/maps uses mapbox-ios at least 6.3.0
Version 6.3 added support for Xcode 12 and iOS 14. Without this hardcoding we get version 5.7. Let's keep the hardcode, at least until they give us at least that version with the npm package.
To check which version comes with, either remove $ReactNativeMapboxGLIOSVersion and after pod install check the Podfile.lock for version, or look on github https://github.com/react-native-mapbox-gl/maps/blob/main/CHANGELOG.md for versions bundle with an npm version.
Update tried again with mapbox 8.4.0 and getting 5.9 and still need the hard coded requirement, try again next time we update mapbox.
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 mockEnvironmentPayload, 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: artsy#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.
Now.
react-native-config loads the .env file by default. We wanted to use .env.shared and .env.ci instead. We did that by using a patch-package patch, to add our customization.
We can do this better using https://github.com/luggit/react-native-config#ios-1. Take a look at https://artsyproduct.atlassian.net/browse/CX-949.
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.
We can remove these hacks once we switch to Stripe's forthcoming official react-native library.
These are fairly superficial styling hacks for
- focused/error border states
- shrinking the icon size to work nicely with our inputs
- aligning inner inputs nicely
- icon animation to work properly on android
- palette v3 colors
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 storybook is upgraded to a version that does not use the removed Cancellable from lodash in that file.
We get an error like here, and that is the solution. DefinitelyTyped/DefinitelyTyped#47166 (comment)
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.