Going over the history of React Native
Back in 2012, Facebook announced they were becoming a mobile-first company. Facebook realized its users spend more time on their phones than on computers. They needed to have their websites and apps working seamlessly on smart devices. However, the majority of Facebook engineers were web developers. The company started researching options to reuse the knowledge of those web developers for mobile development. After trying out a few different ideas, they didn’t want to follow in the footsteps of Ionic, enclosing the apps inside WebViews. They needed something new.
That is when a developer named Christopher Chedeau made his mark on the history of software development. He teamed up with Jordan Walke, Ashwin Bharambe, and Lin He for an internal Facebook hackathon. Basing their work on the first attempts done by Jordan – who, by this time, had been able to generate UILabel in iOS from JavaScript – they created a working prototype that could generate native UI elements from JavaScript on the user device. And it took them only 2 days!
The history of React Native: Facebook’s Open Source App Development Framework
You can read the article here: https://www.techaheadcorp.com/blog/history-of-react-native/.
After this initial success, Jordan and Christopher were able to continue working on their new product, named React Native, with an entire team of engineers.
After 3 years, they were ready to present what they had to the world. The official announcement for React Native took place at ReactJS Conf in 2015. This was the first ReactJS Conf, and React Native was presented during the keynote! That’s how much faith Facebook had in this framework. I encourage you to check out the talk; you can find a link in the official ReactJS docs at https://reactjs.org/blog/2015/02/18/react-conf-roundup-2015.html.
Since 2015, React Native has grown and changed a lot. Some changes, such as the introduction of hooks and context, were simple follow-ups to changes happening in ReactJS. In other cases, changes were motivated by the community or proposed by the maintainers of the framework. React Native on github.com has a whole section called Discussions and Proposals (https://github.com/react-native-community/discussions-and-proposals). Everyone is welcome to add anything they would like to discuss on the topic of React Native implementations, ecosystems, and so on. This board is a great resource for what is currently going on and what may be expected to happen in the future. One of the first issues on this board, the sixth issue to be exact, was a proposition for a Lean Core. By this time, React Native has been in the wild for at least 3 years and it has grown a lot. The framework has included implementations of UI details such as Switch, or native functionalities such as push notifications. One of the core maintainers of the repo proposed that all code that is not absolutely necessary be removed from the main package. You can read more details on Lean Core here: https://github.com/react-native-community/discussions-and-proposals/issues/6.
Of course, answering the question of “what is necessary” and “what isn’t” is not easy. The Lean Core took a few months of discussions and breaking changes. The shape of the main React Native package today represents the results of this effort.
In the meantime, the Lean Core initiative energized the community to go ahead and create their own libraries, which could be useful for React Native apps. As of writing this book, there are hundreds of libraries to choose from when you decide to create a React Native app. There are UI libraries, navigation libraries, async storage management libraries, and many more. This is a blessing and a curse because not every library is well-written and maintained correctly. You can, unfortunately, happen to use something that may break your app in the future. So before running to your terminal and typing yarn add, you may want to use the React Native directory: https://reactnative.directory. This website provides metrics on open source libraries, which are very helpful when you want to add a good dependency to your project.
There are a few libraries that stand out so much, and they are considered to be recommended for React Native projects. Those libraries are usually pretty mature and well-maintained. One example is React Navigation, the go-to library for apps that need anything more than one screen. React Native Testing Library is a library officially coupled with Kent C. Dodd’s React Testing Library. Reanimated is an animation library, which achieves better performance than any of its competitors.
An important part of the React Native ecosystem is Expo: https://expo.dev/. Expo is both a framework and a platform for React Native applications. It offers its users a set of tools useful for developing, building, and deploying apps.
What does that mean specifically? Expo is a thin layer on top of React Native, aimed at making the life of developers easier. If writing an app in React Native was like eating a grilled steak with your hands, Expo would be like eating Filet Mignon with a baked potato and a side of Caesar salad. In a fancy restaurant. You may very well prefer the former, but you cannot deny the obvious advantages of the latter. If you decide to use Expo, you will find local environment setup instructions in the official React Native docs: https://reactnative.dev/docs/environment-setup. Once the app is set up, you will be able to take advantage of the many components created and maintained by the Expo team. This way, you may save yourself a few headaches and performance problems. When you’re ready to show your app to the world, you can upload your app bundle to the Expo website and use it for testing and deployment. As you can see, Expo is a very versatile tool.
Now that we’re up to speed with the history and the current state of React Native, let’s move on to looking at some real-world apps that use it.
