React Native vs React: A Couple First Impression Differences part 2
Last week I began to note some of the major differences I found as someone with React experience who is a newcomer to React Native. I will continue this week with some more variations.
For those new to React Native, the transition from React is not terribly difficult once your environment is up and running.
This setup process takes a bit of time, but it is required to see your work in action. Unlike standard React apps, which you can run in the browser, with RN you must install simulators, which mimic the layout of iOS and/or Android devices, or you must download an app for use on your personal mobile device.
I won’t go through the entire setup process, but as a Mac user, I had to download Xcode from the App Store (a pretty large file and slow download) to get the simulator running.
When I Yarn start from Visual Studio Code, instead of going to localhost:3000, I’m taken to another localhost location, which utilizes Expo CLI to either connect me to a simulator or to the Expo client app on my phone through a QR code.
Another disclaimer that I’m new to RN, so I am surely making some mistakes. But I do have some minor gripes regarding my development thus far.
I have found the simulator less reliable and slower to update than simply running the app on my own phone.
Even when running on my own device, though, I find myself having to disconnect and restart the server with far greater frequency than I ever had to when running an app in the browser. I find the need to restart comes most often after I correct a mistake, such as a syntax error. Instead of simply refreshing, I have to disconnect from the server and reconnect to see the corrected update I have made.
Even with this downside, it’s worth it to see the program running in the native environment.
Back to native app creation!
In a typical React app, when you need to render a list of items, for example when returning API results, you map over the array to show its contents.
RN has a built-in component called FlatList to handle this common rendering need. It utilizes lazy loading, so it is quicker and more performant as the size of the list grows.
FlatList also has a variety of props, which give you more control over how your rendered list will look. For example, there are props which allow you to specify whether to return the information horizontally or vertically, and further, whether or not to display the scrollable indicator. There is an especially helpful prop called keyExtractor, which allows you to take care of React’s pesky need for a unique key for every item in a list.
The FlatList component is a great tool with far more bells and whistles than your standard map. It’s one of my favorite updates I have found yet as a newcomer.
I’ll continue my updates as I find notable differences.
