Discussion about the present and the future of React Native during RNEU 2020 Conference
During the React Native EU 2020 conference, we had the great pleasure to host 24 talks with speakers from all around the world representing such companies as Facebook, Microsoft, Infinite Red, Wix.com, and many more.
In this article, we gathered questions related to React Native itself and the talks presented during the conference.
First of all, let's go through some questions from the latest episode of our The React Native Show podcast. During this talk, our host, Mike Grabowski, and his guests:
- Monica Restrepo – Software Engineer at Major League Soccer
- Kudo Chien – Software Engineer at CloudMosa
- Eloy Duran – Principal Software Engineer at Microsoft
- Ram N – an Engineering Manager at Oculus
are discussing such topics as:
- The new architecture of React Native
- The multiplatform aspect of the framework
- General development of React Native.
Last year, the React Native team announced changes to the core of the framework including:
- TurboModules - a new implementation of native modules for better performance and synchronous access,
- Fabric - just the UI layer re-architecture, to take full advantage of concurrent React architecture
Now, let's move on to the questions.
What is the status of the re-architecture? What changes are already shipped and when do we expect to have an update on the rest of them?
Ram: This is the question that people have been asking a lot of times. I can clearly see how people can't wait to get their hands on the new architecture but I wanna be careful while talking about it. So, there is no "release" for the new architecture in the sense, that there won't be one single date where things stop and suddenly React Native switches into the new architecture.
The initial plan was to try to get it out in 2020 but unfortunately, the productivity of a lot of people went down, and, as a result, we may not be able to hit 2020. We are looking at 2021 as a time that the new architecture could get out but I don't have a specific date in mind.
Since it's beginning, React Native was all about cross-platform and although it shipped only with iOS and Android, we knew that other platforms were just a matter of time.
In this year there were a lot of great contributions from our partners (for example Microsoft) on such platforms as Windows or macOS. Having in mind the popularity of this subject, we couldn't omit the question about sharing code between mobile, web, and desktop.
With new platforms being released and becoming production-ready, what opportunities do you envision when it comes to sharing code between mobile & web (traditional React & React Native targets) and desktop environments? Do these have a lot in common?
However, I think it's always good to reiterate with React Native. It is not about writing once and deploying everywhere but about learning once and writing everywhere. This is similar in the case that you will have to put in some care to make an application on the desktop which I think is what the users deserve.
As the performance is always a hot topic, we received a lot of questions related to the best practices and interesting challenges we're all facing in our daily duties. Here are some of them.
What was the biggest (and latest) performance challenge that you have faced at your job and how did you solve it? What were the takeaways from the solution?
Monica: There are actually multiple performance gaps and challenges that we are faced with all the time. I guess the most challenging that we have had in recent times has been the massive upgrade of our app. We were trying to migrate to Android dex. It sounds like to be something way behind because we have a lot of libraries that we depend on, and like so much of like native code, we were just recently doing it. After that, the upgrading of some of our major libraries like React Navigation for instance made the process of migrating overall very challenging. Especially, because we had some libraries that were already considered "legacy code" and had changed everything internally.
This particularly forced us to think about ways to solve issues like total incompatibility with the new API. As a result, the whole process led us to have great increases in performance. It was definitely something that every person who is developing in React Native always has to face. I think it was important to bring it up here because we also face it at MLS. Having a bunch of interviews working on and just being an app that we have developed for a long time already.
It was only a few answers from our podcast with the React Native EU 2020 Q&A session. If you'd like to listen to the full version, you can find it here:
Now, let's move to your questions related to the talks. We will go through Q&A with:
- Pavlos Vinieratos from Artsy
- Sanket Sahu from GeekyAnts Software
- Gant Laborde from Infinite Red
- Alexander Kuttig from Horizon Alpha
- and Fabrizio Bertoglio.
Pavlos Vinieratos - Xcode complexity? No more.
In this talk, Pavlos explains how to deal with problems with Xcode.
Does XcodeGen handle multiple targets & entitlements?
XcodeGen docs mention other alternatives such as Tuist, Xcake, or struct. Have you tried using them? Also, how easy do you think it is to integrate it into an existing project?
I have tried a lot of alternatives listed there and others not listed, and I found the combination of XcodeGen + xUnique to be the most consistent. I hope at some point in the future to be able to remove xUnique and have XcodeGen take its part, by generating a project in a consistent re-creatable idempotent way.
It’s easier than expected. My repo takes care of the initial generation of the YAML file, but you can still do it yourself by looking at the XcodeGen docs and examples, and only grabbing the makefile from my repo, or even look at the YAML files in my repo as examples/inspiration.
When I have an XCode project with a lot of changes, I would have to create this YAML file by hand for the first time. Right?
Creating it yourself from scratch can be a bit more hassle, but it can be rewarding, and definitely not as hard as it might sound. I would say that first of all, try to use my YAML files from here and build on them. It will give you a good base to build on. I would try taking that YAML file, try to build the app, then add things on the YAML file as I need, to make the app run, to add the other targets, etc.
If you want to completely create your own, definitely take a look at my YAML files for inspiration as well as the examples in https://github.com/yonaskolb/XcodeGen/blob/master/Docs/Examples.md, and definitely read the docs, or at least look at them as you go.
Start from the Spec and go from there.
Sanket Sahu - Building Real-Time Multi-User Apps with JSON Patches.
In his presentation, Sanket describes how to use JSON patches with React/React Native to build a framework for real-time multi-user apps.
I'm playing catchup with the stream. What are the deciding factors to take into account when having to decide between your manual sync solution and out of the box services available such as Firebase Storage or Realm?
SyncState is a state-management solution for the entire app, much like Redux and MobX. SyncState can be extended to sync the state with a DB on a remote server while using the same API.
Out of the box services like Firebase Storage or Realm solve similar problems but we can’t use them for local state management and moreover, choosing between SyncState and those services is like choosing between custom solutions and managed services.
Is it a good idea to try SyncState while creating a personal notetaking app?
I think using SyncState to build a personal notetaking app is a perfect use-case because at some point we would like to take the state to the cloud and sync to other devices. We use SyncState for general-purpose state-management as well.
Gant Laborde - Who Said It?
Gant decided to look at his professional development from a wider perspective. In this talk, he shares his thoughts about learning new skills and the importance of staying updated with what's going on in React Native community and pushing yourself outside the comfort zone.
Have you worked with Hasura? If so, how does it compare to AWS?
I have not - I’m definitely eager to compare the two.
Is there a free tier for hobby projects where you get all these cool AWS features?
Yes! I highly recommend you start there!
Did you or your team at IR put together those comic assets? Or was it from a third-party?
Normally I depend on my Infinite Red team for graphics, but due to the speed at which I wrote this, I purchased these assets, so as not to burden them with my conference hurry!
Alexander Kuttig - The power of process automation brought to React Native development.
In his talk, Alexander explains how to ensure quality through automated PR checks and automated E2E tests on real devices as well as how to save time by automating all steps, for which no human is required.
Have you managed to get BitRise workflow editor working offline?
We didn’t try to, so no :-)
Also, do you tag your releases in BitRise? (Tags not supported in App Center)
We are working with tags in our repository, so no, we do not tag our releases in Bitrise.
Isn't taking the screenshots for all those locales and devices a huge task for marketing?
Yes, it is. But we don’t have to change them for every release.
Do you automate uploading your screenshots and videos from Detox to App Store Connect and Google Play Console? (Trick question, because I don't think it's possible yet)
No, we are not doing that at the moment.
Great talk! Thank you for sharing. How does your team handle regression testing? Or is that covered in your E2E testing with Appium/AWS Device farm? It is such a huge pain point for my team.
It is handled with our e2e tests.
Why not using Appium for iOS as well?
Detox, from my point of view, is much more developer-friendly and has a much larger community - especially when integrating with RN Apps. So for testing iOS Apps or Android Apps on the simulator, I would go with Detox.
Is Detox that much better than Appium?
We didn’t use it for iOS for the moment, because we didn’t need it, since nearly all our device-specific bugs were occurring on Android. But we will use Appium for iOS in the future as well.
Fabrizio Bertoglio - Contributing to React Native is easy.
In this presentation, Fabrizio dives into details of contributing to React Native going through the following steps:
- Contributing to React Native
- Setting up the development environment
- Understanding React Native project structure
- Finding an issue to solve
- Publishing pull request contributing to react-native-camera.
Is the KeyboardAvoidingView UI bug fix on a PR?
Yes, https://github.com/facebook/react-native/pull/29292 and was merged to master with commit https://github.com/facebook/react-native/commit/45954ac5dccdfe05de7553a0f08c4f0e66e3d62e. Thanks!
We hope that you found these Q&A's interesting and somehow they'll make your daily work with react Native easier. Once again, we'd like to thank everybody who took a part in React Native EU 2020 and we hope to see you again next year!
<p-bg-col>Note: If you'd like to watch more talks from React Native EU 2020, you can find the whole playlist here:<p-bg-col>