{"id":517,"date":"2019-04-03T13:44:26","date_gmt":"2019-04-03T10:44:26","guid":{"rendered":"https:\/\/flatlogic.com\/blog\/?p=517"},"modified":"2025-02-09T18:49:50","modified_gmt":"2025-02-09T15:49:50","slug":"the-biggest-react-native-starter-update-so-far","status":"publish","type":"post","link":"https:\/\/flatlogic.com\/blog\/the-biggest-react-native-starter-update-so-far\/","title":{"rendered":"The Biggest React Native Starter Update So Far"},"content":{"rendered":"\n

We made a number of significant changes in React Native Starter<\/a>. In fact, we made a completely new React Native Starter from scratch. It is possible that a few years from now we will look at our work and develop new ideas and make core changes in our product. We believe this is the only way to follow best practices and changes in React Native <\/a>itself. Revisions of architecture and functionality helped us drastically cut development time of future mobile apps. We believe that speed is the most important criteria in this case. Almost every change that we made was either making the process of customization faster or reducing the number of bugs in your future mobile apps.<\/p>\n\n\n\n

\"React<\/a><\/figure>\n\n\n\n

In this article, we want to share some thoughts about the decisions we made creating the second version of React Native Starter<\/a>. And of course, we appreciate your comments, emails and commits on GitHub<\/a>. We want to thank all of you who sent any kind of feedback on the first version of React Native Starter. It was very meaningful and informative, and what is more important thought-provoking.<\/p>\n\n\n\n

Removed Expo and transitioned to native projects<\/strong><\/h3>\n\n\n\n

This decision was made because of lots of restrictions that expo adds to your projects. One of our primary goals with RNS is to provide as much scalable solution as possible. The previous version of our starter kit has been built using Expo framework and it was creating some restrictions for our users. Just a few examples: application builds were large (25+ MB with a plain project), lack of native modules, poor support of offline-features and much more. Also, we believe that our starter kit can be used in a complex application where you might need to adjust the native code (Objective-C or Java) and you wouldn’t be able to do it using Expo. We received a lot of feedback from you, our users, and decided to get rid of Expo in the new release. And because of this change, 2.0 version doesn’t have the backward capability with the first one. <\/p>\n\n\n\n

Added Plop generator for easy development<\/strong><\/h3>\n\n\n\n

Another important goal for us is to speed up the development process as much as possible without affecting quality. And Plop is one of our main improvements in this area. First of all, you probably already know that our starter kit has a modular architecture (if you don’t, please read more in our documentation<\/a>). And after you downloaded our kit, you want to add your custom modules and components. With our Plop config, you’re able to generate all the required files and imports simply by running a single command. Just type plop in your command line, answer a few questions and you’ll have a new module or component ready to go! Magic, huh?\n \"Professional <\/a><\/p>\n\n\n\n

Added support for unit testing with Jest and Enzyme<\/strong><\/h3>\n\n\n\n

Everybody loves tests! Well, you should \ud83d\ude42 With our starter kit, we want to help you to deliver as stable code as possible. We’ve added 2 options to write tests: unit testing with Jest\/Enzyme toolbox and e2e tests with detox. Let’s talks a little bit about the first one. Jest and Enzyme are the libraries that can make unit testing of a mobile app possible. These libraries can help you test your components and functions by writing simple and elegant unit tests. Enzyme adds support for snapshot testing (read more here<\/a>).<\/p>\n\n\n\n

Added support for e2e testing with Detox<\/strong><\/h3>\n\n\n\n

E2e refers to end to end testing which means that application is tested by checking all the layers, interfaces, etc. separately to make sure that these tests show a comprehensive UX image. You can write tests for user stories. For example, you write a test for the login process, it contains the following steps:<\/p>\n\n\n\n