👀 See comment on top of file for template.

Maybe sometime end of 2020, we can change the file EchoNew.json back to Echo.json.

https://artsy.slack.com/archives/CDU4AH60Z/p1600737384008500?thread_ts=1600642583.000100&cid=CDU4AH60Z

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 we upgrade to react-native 0.67 or later.

This is an old restriction for an old hermes version. It's messing with our xcodeproj file for non-M1 macs, so we patch it out for now. That restriction is fixed and removed on RN 0.67.

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.

When we upgrade to RN 0.69. See: facebook/react-native#33756

Jest 28 changed the way it handles transformed file input.

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: 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.

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/core properly 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 in src.
• We make sure that files which do not change are not overwritten. This prevents excessive reloading by metro.

We can remove this hack when we can pass Blob/File with specified name field to fetch() and we won't get an error on Android

If we try to pass Blob/File with specified name field (if we forgot to specify this field, Metaphysics will assume that no file was passed) to fetch(), we will get an error on Android. For this reason, support for these data formats is extracted from upload middleware.

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 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: artsy#6348

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.

When react-native-async-storage/async-storage#746 is solved.

The types in this package are not correct, and there is a type error that comes up when we try to use it. It's a type error on the mock declaration, so we don't really care for it, so we just add a ts-ignore instruction to that declaration.

Unsure.

The types in this package are not correct, and there is a type error that comes up when we try to use it. It is a helper package only used for developing, so we are not afraid of wrong types causing issues to users.

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.

When the fix is in a release in the library or when we stop using this library.

With updated react native version (66) this library causes an error calling the now non-existent getNode() function, it is fixed on the main branch in the library but has not yet been released on npm.

When this is merged, or when storybook supports rendering outside the safe area.

Storybook does not render outside the safe area, so for Screen and friends, we can't really use storybook otherwise. With this patch, we can now render outside the safe area, by adding parameters: { noSafeArea: true } in the new form of stories.

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 remove it and have yarn type-check pass. They have some broken types and they are messing with our typechecking, so we will ignore until they are fixed, maybe in a future version.

Types failing because of broken types in the package.

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