Chain React Conf 2017: An in-depth recap of the first React Native Conference
Bundlers, Payments, Bridges and DevOps
Ihad the pleasure of attending the Chain React Conference 2017, the very first React Native conference in the US and ended taking a lot of notes throughout the talks. I figured the best way to consolidate the topics discussed was to write about them. Unfortunately, not all community members and React Native developers have the ability to attend conferences, so this is a way to share the knowledge I’ve learned back into the community.
I decided against giving descriptions/thoughts on every talk from the Conference as this would become a much longer post. In addition to that, the Infinite Red team will be releasing video recordings of the talks (and BTS) in a couple of weeks so you will be able to watch the talks on YouTube.
What follows below are my own thoughts about some of the talks that most resonated with me.
Welcome & Introduction
The Conference starts with Infinite Red’s co-founder Jamon Holmgren welcoming us to the first React Native Conference and giving us the details about the upcoming days we’d be spending together. Not long after that none other than Gant Laborde, Infinite Red’s Chief Technology Strategist, takes over as MC and welcomes our first speaker, Mike Grabowski, talking about the Dark Art of Bundlers.
The Dark Art of Bundlers — Mike Grabowski
Mike, from Callstack (also a core React Native contributor), walks us through his recent initiatives for replacing React Native’s default packager, Metro Bundler, with a friendlier and less-coupled alternative. The alternative presented is called Haul, and aims to be a drop-in replacement for the react-native CLI, built on open tools like Webpack.
Haul has the ability to act as a development server and it can also bundle your React Native app for production. It aims to provide a better platform interface when dealing with the bundling of React Native applications. Mike explains that the Metro Bundler does a whole lot more than just bundle your code and serve it to an emulator/device. It actually is a thin HTTP server with lots of tightly-coupled tools around it (think Remote Debugging, Live Reload, etc.). You can imagine how substituting that HTTP Server for a simple WebpackDevServer wouldn’t just work. Haul instead leverages WebpackDevMiddleware to create a custom server and bundle the React Native application, whilst connecting to the same suite of tools Metro Bundler uses.
Haul’s mission is to create an easily extensible and truly pluggable React Native bundler. It currently leverages Webpack, given the awesome and vast nature of the existing Webpack ecosystem, but there are plans to support other bundlers, such as Fusebox and Browserify. One other key difference is that Haul doesn’t rely on the watchman package to watch for file changes, and therefore symlinks will work with your application. Given certain use cases, this can be a very important addition.
React Native Sandpaper — Brent Vatne
Brent Vatne, from Expo, starts his talk by walking us through the case for education outside of the official [React Native] documentation. He discusses the need to address this fundamental issue within the community. For someone learning React Native right now, there is a plethora of options to choose from as learning resources, and it can be overwhelming at times. There are just too many video courses, too many books, too many blogs, and too many tutorials out there. Although there are topics worthy of lengthy blog posts, one shouldn’t have to piece together multiple posts and documentations in order to understand the tool or platform.
If your aim is to create impact in the community, instead of writing your own blog posts, Brent urges us to consider working on improving the official React Native docs. The number of people that read the docs are infinitely larger than those who read your Medium blog post.
He goes on the show, step-by-step, that submitting pull requests (PRs) to an Open Source repository like React Native can seem pretty daunting, but is really rather simple. Nonetheless, if PRs aren’t your thing, you can always help by triaging issues on GitHub and StackOverflow. Brent explains that when triaging issues you should aim to see it as a learning experience, rather than just debugging someone else’s problems.
He also touches on a very valuable topic that seems to escape some folks in the community: little details matter. React Native is now mature enough that we can build scalable complex applications using it as the base stack. It is now time we make it buttery smooth and performant, so that the distance between Native and React Native is ever smaller. For example, when dealing with complex animations, handling lots of data or implementing gesture responders, we might not always be using the most performant and bug-free approach. Now imagine the code used in each 3rd party library you install in your application. Does it use the best approach, is it performant, does it break with lots of data? Seeing this issue first hand, Brent and some other folks started a new initiative called Native.Directory.
Native Directory aims to be a helper guide to finding healthy, maintained and recommended React Native libraries that you can safely use in your projects. That way you don’t need to pick and choose from two almost-identical library solutions, and you can feel at ease knowing that there is a larger chance the maintainers of the packages are active enough to at least give you pointers if you happen to face bugs or issues. So far the libraries I’ve seen at the top of the lists are ones I have previously used in my projects, so go on and try Native Directory for your next project.
Accepting Mobile Payments with React Native — Naoufal Kadhom
Naoufal, a Senior Software Engineer at Netflix, walks us through the current state of payment services available on the Web and Mobile platforms. With the introduction of the Payment Request API on Chrome, web checkout experiences can be reduced to one method call. No more custom checkout forms and no more client-side validation, just a native unified checkout experience. Naoufal then tried his hand at implementing a similar approach on mobile. He presented us with React Native Payments.
React Native Payments is a thin wrapper around a Payment Request API polyfill that allows developers to leverage truly-native checkout experiences while still targeting credit and debit cards, as well as Apple Pay and Android Pay (soon). It follows the same specs as the web Payment Request API, which provides server processing, payment processing, shipping prices and shipping addresses, as well as contact information.
The library aims to reduce the friction between the product and the consumer. Not only does it allow for default information (contact, address), it can also leverage previously saved credit and debit cards. In addition to that, if Apple Pay is activated, an application can now make use of the TouchID and activate one-touch checkouts in their platform. Check out React Native Payments and help the library reach 1.0!
Breaking Down React Native Bridging — Peggy Rayzis
Peggy Rayzis demystifies the React Native bridge with her talk, explaining when to create a bridge and all of the pain points involved along the way. She states that you should only need a bridge in three occasions: if you need to integrate a 3rd party library natively, if high performance is crucial to your application or if you need access to a platform specific API. Peggy stresses that unless you check one of these boxes in your application, you should aim to stay on the JavaScript side.
She goes on to explain the internal mechanics of the React Native bridge and what the MessageQueue is comprised of.
MessageQueue is the pipe through which both native and JavaScript parts of your application communicate.
She urges us to keep in mind that the bridge really is a single bridge, and that we should avoid using it unless we need it. When running into performance issues in your application, you are most likely having a congestion in the MessageQueue pipe due to so many messages being sent back and forth between native and JavaScript worlds. Peggy offers us a couple hints to prevent MessageQueue congestion when writing a bridge module: limit passes over the bridge, keep your data flat and write your business logic in one side (native or JS). Especially if you aren’t an experienced native developer, you should aim to keep all logic in the JS side as it will be much easier to debug.
Talking about debug, Peggy also explains that while debugging a bridge module is not super straight-forward, there are tools in the React Native community that you can leverage for aid. She starts by showing us how to use MessageQueue’s own .spy() method that logs out all the messages going through the bridge. She also gives us an alternative tool called rn-snoopy which provides some nice helper methods.
Peggy explains that through the bridge modules she’s implemented in the past, the major pain points were the same. The context switching between different programming languages across different files can make implementation quite difficult. On top of that, there is a lot of boilerplate code that needs to be written so that React Native is able to identify your bridge module. Having learnt a lot from her workings with the native bridge, Peggy decided to release the react-native-create-bridge package, which aims to be a one-stop CLI tool for when native bridges need to be written. You can choose different languages (Swift/ObjC and Java/Kotlin) as well and it writes all of the necessary boilerplate code to make the bridge work. Next time you’re writing a React Native bridge, try Peggy’s new React Native Create Bridge package!
From Zero to DevOps — Parashuram Narasimhan
In Zero to DevOps, Ram walks us through the setup of a simple app with the new Mobile Center service from Microsoft. It was awesome! Automatic building, cloud device testing, code signing and beta distribution were some of the topics covered. And it was surprisingly simple and straightforward.
Paired with a great configuration for the react-native link utility, the Mobile Center SDK for React Native is easy to install and will automatically link all native dependencies for you, in a few CLI steps. And that’s it, your application should be connected to Mobile Center and you are ready to go! Mobile Center is comprised of a great set of tools. It treats React Native as a 1st class citizen (along with iOS and Android) and makes CI a breeze with automated builds and distribution. Ram also shows us other features like CodePush and Push Notifications that make this even more powerful. And if it wasn’t enough, it has baked in Crash Reports and real-time Analytics.
I’ve personally started playing with Mobile Center for a couple projects and have had no complaints thus far. Next time you are setting up your project’s CI/Notifications setup, think of Mobile Center!
React as a Platform: A path towards a truly cross-platform UI — Leland Richardson
Leland walks us through Airbnb’s issues when dealing with the development of one app throughout multiple platforms. The company currently has 3 distinct applications — Android, iOS and Web. Even if it were to move all mobile development to React Native and web development to React, it would still be comprised of two codebases. Although the same React concepts can be applied to both applications, Leland explains that in this case, it is almost more burdensome to the developers working on the project as they will need to implement almost identical features that just happen to be targeting two different platforms, web (div, span) and mobile (View, Text).
That being said, he shows us that there is a set of 7 core APIs that comprise around ~80% of most React Native applications. These are Animated, Image, Platform, Touchable, Text, StyleSheet, and View. He argues that most of the other core components can be built using these 7 primitive APIs. He presents us React Primitives, his response to the issue of targeting different platforms.
“[React Primitives package] attempts to propose an ideal set of primitives around building React applications, regardless of Platform. In the future, this could be used as a shared interface among React and React Native components that don’t use platform-specific APIs.”
Leland shows that there is a lot of work involved in creating truly cross-platform user interfaces in React, but that it is rather feasible if the community is behind the initiative. Can you imagine writing once, and running anywhere? React Primitives is trying to achieve this and Leland, along with some other folks from the React Native Web team are spearheading this initiative.
Leland gave a similar talk in the last React Europe Conference, you can check that out here: https://www.youtube.com/watch?v=hNwQPJy-XZY.
When to Go Native Over JavaScript — Harry Tormey
Harry Tormey is an experienced iOS and Android Engineer that has fully embraced the React Native community and talks to us about when to go native over JavaScript.
It shouldn’t be new to you, but React Native gives you full access to native capabilities on both platforms — iOS and Android. By leveraging Native Modules and requireNativeComponent, one can write Java/Kotlin and ObjC/Swift components and import them on the JavaScript side for use with JSX. It is a powerful feature, but there are always pros and cons to choosing a native solution inside a React Native stack.
Harry uses Navigation, a community pain point (that will hopefully be put to rest soon), to demonstrate the various impacts of choosing a native solution. To begin with, he explains that choosing to go native is a choice developers have to make before setting up their initial project stack. When using Expo or create-react-native-app, you give up the ability to write custom native modules (unless you detach from Expo, which may lead to other pain points). The same is true when dealing with CodePush — native code changes require a new Store submission while JavaScript changes can be applied over-the-air.
Harry makes a good case for the distinction between React Native Navigation and React Navigation, the former a native solution and the latter a JS solution. He shows us performance differences and stats comparing the two approaches as well as the cons involved on both alternatives. My takeaway from Harry’s talk was something along these lines — if you are not used to the native languages and platforms at hand, you should aim to stay in the JS side of the application, unless crucial app requirements dictate otherwise.
React Native on the AppleTV Platform — Doug Lowder
Doug Lowder, a Software Engineer at Salesforce, talks about tvOS and how React Native fits in with the AppleTV platform. In his presentation, Doug walks us through a great demo, built in React Native tvOS and show us the differences and similarities between the iOS and tvOS platforms.
When using React Native to target tvOS one must remember that the iPhone and Apple TV experiences are infinitely different. First of all, there’s no touch (like we know touch from iPhones) involved in Apple TV, the experience is guided through the Apple Remote. Therefore, the application requires a completely different UX. In addition to that, the platform doesn’t provide certain components that exist when targeting React Native for iOS. Things like Sliders, Switches, StatusBar, and other APIs just don’t exist in tvOS. Currently, it is also impossible to persist any sort of data to disk, so all data used in the application must be fetched from network sources.
Taking the above into consideration, Doug shows us that it is still completely feasible to achieve production-grade applications using React Native for AppleTV. Unsplash is an example of a tvOS app built with React Native and I’m sure there are more coming soon. In addition to some tips on performant list rendering, Doug explains that although targeting different platforms, more often than not React Native for iOS libraries can be leveraged for tvOS as well. VictoryNative Charts by FormidableLabs, for example, works almost entirely in tvOS, without any changes out-of-the-box. The platform is still growing and APIs are always improving, but Doug makes a great case for using React Native for AppleTV.
Packages Worth Mentioning
Throughout the talks, speakers mentioned some 3rd party libraries that I thought were worth putting down here:
- React Native Generator Toolbox — Yeoman generators for React Native with lots of goodies.
- React Native Create Bridge — CLI tool that bridges React Native modules & UI components with ease.
- React Native Create Library — tool used to create a React Native library scaffolding.
- React Native Snoopy — profiling tool that lets you snoop on the React Native Bridge.
- Haul — command line tool for bundling and developing React Native applications.
- Metro Bundler — React Native’s default application bundler.
- Mobile Center SDK for React Native — SDK package for Mobile Center.
- Detox — Gray Box E2E Tests and Automation Library for Mobile Apps.
- React Native Smart Splash Screen — a smart splash screen for React Native applications.
- ExpoKit — Expo’s APIs extracted as a package.
- React Native Payments — accept Payments with Apple Pay using the Payment Request API.
- React Native Gesture Responder — a more convenient and powerful gesture responder than the official PanResponder.
- React Sketch App — render React components to Sketch.
- React Primitives — primitive React interfaces across targets.
I had a great time at the Chain React Conference 2017 and am already looking forward to 2018! I’d like to thank the Infinite Red team for providing the attendees with such a smooth experience — great people, great food, great location. We listened to some great talks and met amazing engineers from all over the US. Overall a great success!
My Name is André Neves. I am a software consultant and a Lead React Native Engineer at Big Human. We’re a digital product design, UX, and development studio.
If you enjoyed the post, please recommend and share it! Thanks for reading.
