Comments: React Native, 2 years later

[orta]

@alloy first mentioned React Native as an option for Artsy back in March 2015, and in February 2016 he made our first commit to get the ball rolling. Since then, we've grown a new codebase, Emission, which has slowly taken over the responsibility for creating the UIViewControllers presented inside our iOS app.

We've come quite far from where we started, and I was asked if I could give a talk to summerize what we've learned in the last 2 years as a set of native developers using React Native.

http://artsy.github.io/blog/2018/03/17/two-years-of-react-native/

[eliotfowler]

@orta Thanks for the awesome talk. It's really cool to see an overview of the ups and downs of react native.

In the video you mention that there is no mobile team at Artsy anymore. I'm curious what that means for eidolon. Are there plans to introduce react native there as well? Additionally, something else I'm curious about is if there were any worries you had about introducing react native initially. You mention that for the most part you're just parsing json and showing the data in different ways, but are there any screens/features that do more than that? I suppose you always have the option of developing a particular screen in native code if need be, which may quell any worries.

Thanks again for the awesome talk!

[orta]

In the video you mention that there is no mobile team at Artsy anymore. I'm curious what that means for eidolon.

For context, Eidolon is a medium-sized Swift app, which lets people bid at a live event. We used Eidolon to safely experiment with Swift while Swift was still in an early stage of its lifecycle. We also have a small Swift app called Emergence, which is our Apple TV app. On the non-Swift side, we also have Energy - a partner portfolio app. So we have a bunch of iOS apps.

All of these need to be maintained, ideally they all need to be running on the current major version of Xcode - so that if there needs to make a release, it will be pretty trivial. The responsibility for the maintenance and feature work used to live inside the mobile team - but now that team doesn't exist.

What happened is that each app was given to certain business groups inside Artsy. We aimed to spread the developers with mobile experience throughout the engineering org and that meant the knowledge would spread. Realistically though, today, only me or @ashfurrow can contribute to Eidolon without considerable on-boarding because of the RxSwift + Swift choice. So if something critical needs to happen, one of us are the ones to do that. We can make time without our respective teams to make that work.

The same thing for Energy where I've not actually needed to do serious work in a year (though one day this'll be ready)

We all are a part of a front-end group in Artsy where we can try to handle some of the more meta issues (deployment, consistency etc) which we share with web devs, but there's also a smaller iOS-front-end that is basically the old mobile team in a slack new channel - but without reporting structure or product management etc.

Are there plans to introduce react native there as well?

For all of these projects, we have little to no plans to add React Native. React Native fits amazingly with an API driven app. The tvOS app side (which is "done") the rest of our Apps are not this. Most of the complexity in Eidolon is around what screen to show when, and we use storyboards a lot as screens are not dynamic. Energy is a "sync once, use offline" experience. Nearly all of our focus is on the main Artsy app, Eigen, where its usually about building the little web-pages inside the app - where React Native excels.

are there any screens/features that do more than that?

Yep, I have spent most of my time in our React Native components building out things that are not pretty JSON parsers, the consignments submission process being the biggest. I think there's a trade-off of complexity here, some of these screens became quite extensive and for me the decision to use React Native for the feature was about whether it would be re-used on android someday, or could I start by copy & pasting from the web. I felt like it would be useful on android, so we went with it. It's not as perfect a fit as an JSON->UI screen, but it was still a pretty 👍 experience.

After that I worked on AR for Artsy, using ARKit, which I skipped React Native completely - it's quite far from what I think React Native is good for. It was also quite an exploratory project so potentially needing to build a middle layer for ARKit and RN wasn't something I was interested in doing.

Falling back to native was easy in cases like this, we didn't de-skill ourselves, just gave new options to build the things we do most of the time better.

[flexaddicted]

@orta Thanks for your talk. Really interesting 🥇

I've spent some time inspecting the codebase of both Eigen and Emission. I need some time to digest it since it's involves a lot of configuration. Do you have a sort of starter template? I'm working on a personal project and I would like to experiment your same approach.

That said, I would like to ask your opinion about React Native and its usage in business projects. As you explained in the talk, you've followed a brownfield approach. The app skeleton is native and, on top of it, you've started to integrate RN components (I like the clean separation between Emission and Eigen). This approach allows you to reuse UI elements and business logic (especially if you have also an Android app). A different approach is to use RN as a whole. Maybe you can also take advantage of Redux in order manage the state of the app.

Between the two I would prefer the former approach (I'm a iOS developer ;)). Even if the second approach can bring advantages in the short term, I think it has a lot of drawbacks, like:

• Taking advantage of availability of specific API available in the native world
• Impossibility to refactor / re-engineer a code developed only in RN if something goes wrong
• Maintainability of native modules due to API changes
• Be unaware of the internal behavior of the framework (it could requires some time to digest it)
• Spend time to add animations, sticky behavior or complex layout
• Managing several dependencies (the ones included in RN and the ones imported in order to integrate modules not included already, e.g. push notifications, WKWebView, etc.)

What's your opinion?

Thanks, Lorenzo

[orta]

I don't have a starter template, I have this post where you can do the entire thing by hand though.

I think you need to use native code to make React Native apps without compromising on quality. If you're willing to compromise on design or feel of an app then going 100% JS can work fine. Using create-react-native-app you can iterate faster, deploy easier and rely on JS dependencies instead of native one. That's fine for many projects. It's not really something I really see Artsy, or myself doing though.

[flexaddicted]

@orta Thank you for the useful info

[stevepepple]

This talk along with all of your other resources for React Native and Javascript have bene really helpful for my team at vibemap.com. Thanks so much!