#tech #technology #react
10. Jul 2019 |
- min Lesezeit
React Native aims to combine the good parts of web and native apps. You get the speed of native apps and the ease of cross platform development of web apps. To be a bit more technical, it uses a Javascript thread with React which communicates with a native UI thread. So all the UI components the user sees are actually fast native components. But the decison what components to show and all the application logic is in the Javascript thread. React is a widely established framework from Facebook for creating complex dynamic user interfaces. It was orignially designed for the web but react native allows it be used for mobile (and even desktop) apps as well. React Native is especially interesting for companies with lots of web, but no native app developers.
RN made it very easy to quickly build very complicated UI cross platform. All the layouting is done with Facebook’s own implemention of Flexbox called Yoga. It really makes layouting a breeze.
React Native goal isn’t to have the exact same UI on Android and iOS. Each platform has its own design language and users expect to look things the way they’re used to. Still, most developers say that they’re able to share at least 75% of the code between the platforms.
Because Javascript does not need to get compilied before deploying, new code can be pushed quickly to the development device. This makes especially creating UI much easier as style changed can be quickly seen and tested.
Their are many tools for the JS eco system and you can use most of them. Yarn, Prettier, ESLint, Babel, Typescript, Jest, Redux are all tools which we successfully used together with React Native. React Native can use these battle proven tools for app development as well.
Because most of the app logic lies in the Javascript code, this code can now very easily be loaded from anywhere. This makes it very easy to load rarely used UI elements on the fly or even replace the whole app without going through the app/play store. While this should be used wisely, it can be a very powerful tool.
If you want to access more specific OS features, you’ll likey still need to write native code. Sometimes plugins are available, but the more specific your wish, the more likely it is that you need to write native code yourself. So suddenly instead of writing one language, you need to master 3. We had this problem while trying to access fitness data from Google Fit / Apple Health.
Both of them are a beast. They require many GBs of downloads and want to be kept up to date. Each has their own build system and configurations which are really difficult in detail. This is often overwhelming for a web developer and needs a lot of time to get used to. Obscure compile errors were the norm for us at the beginning. The expo framework tries to allow react native development without having to deal with these systems. But it’s limited, if you want to integrate deeply with the OS, you can’t use it.
Developers mostly have their favourite platform and silently decide to only test on it. Most of the time, things just work on the other platform, but sometimes they don’t. Developers need to be sensitived to this issue, leave their comfort zone and cross test.
The blank react native repo created with ‘react-native init’ contains platform specific code and configuration files. These files change with every new version of react native. At the same time these files need to be modified by you as well to customize the app. So updating react native isn’t just updating the npm module, but also all configuration & code files. This can be very tricky if you don’t know the platform by heart. Again, Expo makes this much easier by abstracting these things away from you, but also limiting your possibilities.
Stack traces get interrupted on the bridge between JS and Native. JS calls that create exceptions in the native code are very hard to trace back to the original JS code.