things-i-learned-by-shipping-a-react-native-app.md

This is a quick lightning talk about 6 things I learned by working on a React Native app for 3 months.

1 Expo

We used Expo to bootstrap our development.

There are some good reasons:

• Expo allows us to avoid native code, actually, it prevents us from using any native code
• Expo has a bunch of native bridges they provide: Location, Push, Storage, etc
• Expo helped us get our feedback loops way down
  • instead of having to publish betas early on, we could push through Expo and share the QR code it generates to get our stakeholders the living breathing app on - first demo of this was Day 3

Here are some bad reasons:

• Expo prevents us from using native code - and there's a lot of packages that make you use react-native link` out there
  • There's no escape hatch - we wanted secure OAuth, which is supposed to use a CPRNG, but on RN, you can't use Node's and we couldn't break out to native either
• Recently, Apple stopped Expo from using the QR code sharing feature on Android

2 React Is Pretty Nice

If you have been here a while, you might remember me as the Vue guy. I love Vue. I'll tell you a secret: I knew React before I knew Vue. If only there were a Vue Native...

React's userland interface is pretty simple for the most part

There's a lot of great concepts in React and I wish they were more exposed in Vue sometimes.

3 React Native Styling

React Native uses a custom flex box implementation for layout, and emulates CSS properties, since there's not actual CSS styling the screens

We tried using Native Base to design our application for weeks, and we would make progress, make screens, our stakeholders would want a few design style tweaks, and we would be hunting for hours, and sometimes incapable because of poor (and old) design decisions in the Native Base Library

Over time, we started making some of our reusable, independently styled from Native Base, components.

I wish we had a first party solution for managing themes and "style" cascades in React Native, because the third party implementations are slow, old and inflexible.

4 GraphQL, pretty please, probably

Our app is about livestock data, and there's a lot of data in layers of hierarchy. If we had used GraphQL, we might have been able to decrease our load times and increase our HTTP data request payload specificity.

4 CI/CD

• Expo allows for release channels
• Our pipeline is able to build up dev in under 10 minutes, and it doesn't use our own computers
• Once dev is built, the team gets notififed by our

5 Stores, getting big

Redux usually comes along for any large sized project.

We used Redux for...

• central store of all our data, after it left the screen it was made on (i.e. no redux-forms)
• we used it with redux-persist to mirror the state into AsyncStorage so users could get their data back easily when they closed the app, or it was forced from memory
• we used it with redux-offline to have our Action Creators have automatic "effects" for syncing data from the client to the API layer, and rolling back if required

We had, maybe a dozen domain type objects to track. At first we had many of our "creating objects" action creators in one file, but it became way too long, and then we had so many files in our code tree.

6 Enforce prettier and eslint

I was trying to be nice. I setup prettier and eslint configs, and had everyone install the plugins for VS Code, but I didn't enforce compliance.

That was a mistake.

We're still finding files that haven't been formatted with prettier because it wasn't set on pre-commit or on save in the editor. We are still finding files regularly that have had development churn and imports that are not used are still imported. Enforce these!