Having attended the React Native track at this year's React Amsterdam, I got inspired by all the talks and the React community in general. This motivated me to write a blog post detailing my review of the React Native track. For a review of the main track, I highly recommend Átila Fassina’s blog post.

Before I go into detail, I would like to give a big thumbs up to React Amsterdam for pulling off such an impressive event. I can safely say, that, although I follow the React Native community closely, I learned something new in each talk that I attended. The quality was very impressive and the speakers all did a good job in preparing their talks, providing a mixture of theoretical and practical information, including live demos.

Swag from React Amsterdam 2017

Onto the talks. I attended most of the React Native talks since we are actively working with both React and React Native at Simplesurance in Berlin, and I have personally always been interested in mobile development. So, here are my summaries, understandings, and impressions of the talks that I attended.

[All the talks from the React Native track can be watched here]

Coding Mobile with the Pros

Gant Laborde got us in the mood by recommending 3 tools to assist with React Native development:

1. *Reactotron* is an app for inspecting pretty much all the events that take place in your React and React Native applications. You can view the current state of your app, change the state, take (and save) snapshots of the state, hot swap app states among many other things.
2. *Expo* allows you to bootstrap and build React Native apps by focusing on the JS implementation, while expo takes care of a lot of other services and tasks, such as deploying your app to your device for testing and building your apps .ipa and .apk.
3. *Ignite *is a cli and generator of multiple React Native bootstraps. It provides you with a number of plugins and APIs to make your React Native development even easier.

I became very interested in Reactotron, which I think is useful for debugging and testing out how your app will behave in different states. Another cool point is that you no longer need to have the chrome debugger open and you can instead just use Reactotron. I have personally used Expo and can vouch for its ability to quickly get you started with a React Native app that you can have running on your actual device in less than a few minutes. I have not yet used Ignite, but I plan to check it out, it looks very useful!

Web Like Release Agility for React Native Apps

This is one of my favourite talks from the conference. Parashuram provided us with an impressive live demo of Mobile Center. He succeeded in getting an iOS and Android app, made with React Native, onto the audience’s devices in about 20 minutes with the help of Mobile Center, simultaneously making jokes.

Having investigated and dealt with some of the pains involved with CI, building, and signing and deploying of iOS and Android apps, I predict that Mobile Center will do a great job of making this process less painful. At the moment, there is a trial option for Mobile Center. This tool looks very useful and has first-class support for React Native. I would recommend checking it out!

Asynchronous & Offline Magic Tricks on React Native

It is highly probable that your app will be used in an offline scenario. In this talk, WoodyRousseau taught us what we should consider when developing mobile apps for such use cases. According to his “reliable statistics”, apps are most often used in subways which provide little to no connectivity. There were 2 main discussion topics of this talk:

1. Apps must handle failure:

App features should be designed to handle 3 expected states, namely: expected state, loading state, and blank state, thereby taking a “Defensive Design” approach to app development.

2. 2. Apps should avoid failure:

Here, the probability that the user should encounter a loading or blank state should be decreased.

These 2 points were discussed from the perspective of reading and writing in an app. During the talk, a number of approaches and tools were suggested to deal with these situations, including the interesting redux-offline by Jani Eväkallio. I would highly recommend that anyone developing mobile apps, check out this talk since sooner or later you are likely to have to provide offline support in your app.

Lightning Talks

Lightning talks are tough for speakers due to time constraints. Additionally, these talks were just before lunch, so keeping the hungry audience’s attention is another challenge. Nevertheless, the speakers did a great job of giving us useful information and tips in a couple of minutes.

Large Scale In-Store Promotions with React

A very energetic video by Tim Koopman explained how React was used to create Reactman, a Pacman-style game.

Practical Performance Tips Building Mobile Web Using React

Narendra N Shetty showed us how to address the performance issues of mobile web apps. He demonstrated it on an uber clone app which he created. The loading time of the first page was improved from 19189 ms to about 300 ms! Narendra used techniques such as code splitting, SSR, compression, caching, and preloading, to achieve this. You can check out his blog post for more info.

React and Redux Love Web APIs

Ricardo Torres showed us how to add audio commentary to his company's live streaming football website, wrapping this functionality as a reusable react component — pretty cool.

Creating a Pixel-Art Editor Using React and Redux

The speaker, John van der Water, implemented a web app to allow for the creation of pixel-art, including adding frames and layers — all this using React and Redux.

Universal React

I was really looking forward to this talk since we also maintain one code-base for our React web and React Native apps at our company. Mike Grabowski didn’t disappoint and provided an overview of how best to structure your React code-base for optimal reusability. The structure he proposed, looks like this:

Depending on your use case, you might agree or disagree with this structure. In our case, we share the same processes between our web and native apps and therefore prefer to just swap out the rendering of the components. With Webpack set up correctly, you can import the appropriate component by using the extension .jsx or .native.js. However, for highly reusable components that are shared between projects, I think that the approach suggested by Mike is very solid. This approach provides for reusability that scales to current and future platforms supported by React.

Mike also encouraged the use of primitives over platform-specific controls. Check out these suggestions from him: react-primitives, react-native-web, and reactxp.

Performance Limitations of React Native and How to Overcome Them

Tal Kol addressed a topic that I think we are all interested in — improving the performance of our apps. Tal did a great job of explaining the steps used to improve the performance of a scrollable list and image in a React Native app. This simple diagram from his talk shows the high-level architecture of a React Native app.

React Native Architecture

The main take-away point from this talk is:

“Limit the communication that takes place over The Bridge”.

Doing this is easier said than done though. It often requires that changes to the state are known in advance and provided as a declarative structure, which is passed once to the native component. This allows the native component to handle user interaction, thereby reducing the communication over the bridge. However, Tal shows us how to achieve this for his use case in his talk.

Navigating React Native Navigation

Ah, the good old topic of navigation in React Native… There have been a number of attempts to provide an “ideal” navigation approach for React Native apps but up until now, there is none. kurtiskemple talked us through MLS’s journey for choosing a React Native navigation library that worked for them. He provided an analysis of 3 navigation libraries, namely: native-navigation, react-navigation, and react-router.

In the end, they went with react-router as it was the most relevant for their requirements. Kurtis did a good job of highlighting the pros and cons of each library and additionally provided some considerations to take into account when defining the requirements for navigation in your own app.

Testing & React Native: Lessons from the Battlefield

Aaron Greenwald brought a lot of energy onto the stage (literally he jumped onto the stage) which was well received, especially at this time of a long day. I enjoyed this talk since testing React Native apps is still something that doesn’t receive as much attention as testing React web apps. Particularly challenging, is the end-to-end (e2e) testing of React Native apps, since this moves from the JS component level of testing to the testing of native iOS and Android apps, which need to run somewhere and be interacted with somehow.

Aaron talked us through different testing tools for each level of the testing pyramid, as well as some of the pros and cons of these tools. He justifies why he thinks shallow rendering for tests doesn’t really provide an optimal testing approach.

I was surprised to hear that they had a lot of challenges with Appium, as this seems to be the go-to framework in the community at the moment for e2e testing. Nevertheless, we were introduced to an e2e testing framework known as detox. I’m very interested in exploring this framework further even though, at the moment, it has no support for Android e2e testing but it should be supported in the near future, as I understand.

Missed Talks

Unfortunately, I still don’t have the ability to be in two places at once and was forced to miss Krzysytof Magiera’s talk “React Native Touch & Gestures” and Chris Biscardi’s talk “Demystifying GraphQL Clients”. However, I plan to catch up on these talks soon. Instead, I attended the following 2 talks in the main track:

Test Like It’s 2017

Yes, another talk on testing but no-one is complaining. Michele Bertoli did a great job of highlighting the features of Jest Snapshot testing and provided a quote which I think is very interesting (and bold):

“The best way of testing is not writing tests.”

I believe that the underlying architecture and approach of React has allowed for such statements and approaches to be made. Automation tools like react-fix-it take advantage of this standardised and component-based approach offered by React, to make our lives as developers a lot more productive!

I would definitely recommend checking out this talk, as Michele showed us a lot of other cool things.

Flow Typing a React Codebase

Forbes Lindesay gave us a first-hand account of his experience with flow for static type checking. Flow can reach 100% code coverage which can provide a significant improvement to the quality of the code, reducing bugs early on in the development process. Forbes presented us with yet another test pyramid but this time the change was bolder than those before. Here it is:

Testing pyramid by Forbes Lindesay

Adding Static Analysis to the test pyramid was new for me but makes a lot of sense and by default doesn’t require any additional implementation of tests. Furthermore, I personally feel that the lines separating unit/component/integration tests are becoming more blurry when it comes to JavaScript, potentially eliminating the need to have explicit unit/component/integration tests.

Incorporating flow into your existing code-base is not always straightforward, especially if you are using npm packages that do not use flow but Forbes explains, in his talk, how to deal with this among other such issues. He ended his talk by going into detail about how to deal with certain, common, situations that arise when defining types in JavaScript. This reminded me a lot of my days doing Java development, not sure if that is a good thing or a bad thing.

There are definitely a lot of tips and tricks in this talk, so I recommend checking it out if you are using flow or doing any type of static analysis on your JS code-base.

Surprise Talk

To conclude the talks, surprise guests Vincent Riemer and Bruce Lane got the after-party started! But not before a bit of technical detail was provided to the knowledge-hungry audience.

Vincent showed us how he implemented a web version of the Roland TR-808 (which I shamelessly knew nothing about) using React. The effort he put into this is really impressive and the outcome looks good!

Bruce then broke the conference genre by showing us his implementation of OpenGL shaders and coded electronic music (huh?), in c++.

Final Words

After the talks, we could then all embraced the Amsterdam evening and celebrate the end of a successful conference with interesting drinks (such as the space-monkey beer for those who wanted to try something different), snacks and music.

I really enjoyed the conference and the overall experience of React Amsterdam 2017. The quality of the talks is what impressed me the most and a big thank you goes out to all the speakers for putting in so much effort and for sharing your knowledge and experience with us.

The React Amsterdam team took care of everything and did a good job organising such a massive event. Maybe next time, shorter queues would be good, especially for coffeeeeeee ;) Thank you for also including a React Native track, which was very informative.

Last but not least, a shout-out to my awesome team Simplesurance for providing this opportunity. I think we (Átila Fassina, João Lopes, and Petro Moldovan) all made the most of it!

Final Words for Real

It was clear to me that testing was a popular topic at this year's React Amsterdam (I think I have seen more than enough testing pyramids!). However, it gives me an indication that the community is investing even more into the quality, reliability, and robustness of code, not only for private projects but also for community projects. It’s great to see and I feel really positive about the growth of the React community, so let’s keep sharing knowledge, learning from one another, and supporting events such as React Amsterdam.