Comments: React Native, 3 years later

[orta]

Our experience has been really positive building a single platform data-driven app. We've been able to drastically increase the number of contributors to the codebase and with minimal guidance, web-developers are able to be productive and ship features to our iOS apps.

That said, for this 3 year anniversary, I want to dive deeper into some of the less positive aspects of our transition. We think these trade-offs are worth it, and that this may be what a successful cultural transition eventually looks like for some companies.

http://artsy.github.io/blog/2019/03/17/three-years-of-react-native/

[GrandPoohBear]

Excellent post, thanks for sharing! I can identify with having to keep on top of all of those communities. It doesn't help that each seems to have established its own gathering spots and messaging channels! Also happy that there's another net positive post about RN from a reputable source. It'd be just as well if I never saw another reference to the AirBnB episode as being the downfall of RN anyplace other than Facebook :-)

[watadarkstar]

You said "For example, it took almost a year to get around to upgrading our version of React Native. This is a pretty risky place to be for a platform which we care about." Could you elaborate on this?

[orta]

So there's two statements in this sentence:

For example, it took almost a year to get around to upgrading our version of React Native

and

This is a pretty risky place to be for a platform which we care about

The former is easy, we're always going to be supporting this app - so the further we deviate from master the more work it is to keep up to date. React Native changes reasonably fast, but the whole tooling eco-system around it changes faster, so if we want to be up to date with Enzyme, we have to be up to date with React Native. When trying to have a cohesive stack across web and iOS, if your React Native gets out of date then people are wary about updating transitive dips. E.g. We ~can't~ shouldn't use hooks in web because we're not on a React build that supports it in RN.

For example, it took almost a year to get around to upgrading our version of React Native

Is a bit more nuanced, our React Native setup is the same as other big companies because we want a very clean separation of RN code vs native code. Or simply, no node_modules inside native app repos. ( You can read about the architecture here and see how it works here )

in the last year we tried multiple times to update our React Native version:

• https://github.com/artsy/emission/pull/991
• https://github.com/artsy/emission/pull/1117
• https://github.com/artsy/emission/pull/1210
• Which was eventually rebased and merged in https://github.com/artsy/emission/pull/1551

But TBH, our setup is hard because we built a lot of our tooling infra in-house and the jump required updating everything to babel 7, from both react native, typescript and jest. Turned out that was a lot of work, that tended to be pretty frustrating work to do. It was a large diff though, and it's unlikely there'll be another change as fundamental as babel 7 for a long time now.

That said, new versions of RN will have less exported features, so if you look at our latest migration to the latest build, we have to polyfill in features that we want, which have been removed from core https://github.com/artsy/emission/pull/1553 - so it won't be without its challenges, but it's less work and could be handled by product teams at the start of a project.

[tuncaulubilge]

Hi @orta, great blog post, reading about Artsy's experiences with React Native is always super helpful!

I'm curious if you ever tried libraries such as react-native-web or react-native-dom to unify web and mobile components of Artsy. Creating a component library that's shared across web, android and ios sounds like the ultimate goal, but that comes with it's own set of cons. What was the experience that lead Artsy to have separate components for web and iOS?

[zephraph]

Hey @tuncaulubilge! I'm pitching in for @orta on this one.

We generally agree across our team that React Native doesn't mean write once, run anywhere. It's more like learn once, write anywhere. So while we like to share where it make sense, we generally try to avoid making things more complex just for that purpose.

That said, we have specifically explored universal components. Palette, our design system, has a set of universal components. When we were first thinking about how to solve this problem, we experimented with react-native-web (among some other options). Given the general complexity of the solutions, some bugs we ran into, and added difficulty debugging we decided not to go this route.

We use styled-components and have some general platform primitives that let us abstract away the difference between a div and a View. For 80% of what we need that's usually sufficient. For more complex components, we may not even try to share implementations. Instead, we do our best to provide the same API across platforms so that at least they're used the same.

There are still a lot of issues (like cross platform testing) that we have to figure out, but so far our approach of selective reuse is working fairly well.

@alloy feel free to pitch in if you have anything to add.

[tuncaulubilge]

Thanks a lot for the detailed explanation @zephraph , that's quite useful, and exactly what I was hoping to hear. We are using react-native-web in production but we sure had our share of troubles using a write-once approach. I'll take a look at Palette for sure, it's always inspiring to see Artsy's work!