React Native — How Native Have You Been?

February 11, 2018 0 Comments

React Native — How Native Have You Been?

React or React Native, the hype is real and why not? A cut-throat market competition demands an agile product development lifecycle and versatile deployment strategies across vivid application platforms. React Native offers a powerful toolset for cross platform development by maintaining a unified repository throughout the development cycle. It leverages the growing power of JavaScript and JSX to deliver a native-like performance which has awestruck many aspiring and matured mobile app developers.

Learn once, write anywhere.

Now, we will have a comprehensive comparison of React Native with the Android and iOS platforms and their relevant components, instead of immediately diving into the nitty-gritties of this relatively newer library. This article summarises my learnings as a React Native developer in contrast to a native app developer.

Android — Leverages the lucid nature of XML to develop view layouts. Latest flexible layouts viz. ConstraintLayout have enabled developers to express UI wireframes easily into code.

iOS — Primarily offers Storyboards to place UI components. The drag and drop feature has been a relief which almost avoids reinventing the wheel. Like every relief comes with a price to pay, iOS layouts have their own stories. Choosing an appropriate method to set layout constraints still remains a mystery. (StackView? AutoLayout? Constraints via code? I don’t know. Help me.)

React Native — uses JSX, a coupler of business logic and UI. Sadly, the drag and drop feature is missing here and a developer must explicitly declare every UI element as a code block. React Native has embraced Flexbox to define geometry and a CamelCased version of CSS to apply cosmetics. So far, I have been decently able to relate flexbox with Android’s LinearLayout. The {flex:1},{ flex:2} properties imitate layoutweight, while justifyContent and alignItems are closely relatable to layoutgravity in Android. Markup tags viz. Text, TextInput, View, Image have been intelligible and have ironed out the barrier to learn newer terms.

As every Activity or Fragment in Android or Screen in iOS, is based on an XML Layout or a Storyboard Screen respectively, every Component in React Native has a render() method which renders the UI in the app. This method is analogous to the setContentView() in Android, which accesses the layout file of the corresponding activity. Currently, the possibilities to compare React Native components with Android’s every Java or Kotlin class remain acute but, considering rapid advancements the future looks bright.

Another similarity is observed under the Lifecycle banner. Every React Native Component has a lifecycle relating to an Activity or a fragment lifecycle in Android. Components can be stateful(class-based) or stateless(functional) and are reusable anytime in the entire app. A change in state, re-renders the Component. Similar functionality is achieved in Android or iOS with Listeners, Observables or methods viz. notifyDataSetChanged(), notifyItemInserted(), notifyItemDeleted(), etc., which modify the RecyclerView adapters.

In the domain of cross platform application development one of the vital practices is splitting an application into functional modules viz. business logic, views, network communication. This practice promotes modular testing and easy debugging. Recently, Google introduced Android Architecture Components which clearly defines the principles of MVVM. These guidelines are assisting developers to apply core product architecture principles to make robust apps. On the other hand, technologies like RxJava, Dagger2 are already adopted by regular developers which contribute to the same concept of systematic product development.

React is blessed to have Redux and similar modular concepts that provide exquisite control over component states. It’s due to Redux I was able to develop and deploy mobile and desktop apps with the same business logic. Trust me with this fact when I say, “The business logic was untouched and the only change in the entire application was writing the front-end layouts separately for web(ReactJS) and mobile(React Native)”.

Although with the ‘Learn Once, Write Anywhere’ mantra, sometimes platform dependant implementations(Android or iOS) demand a native code dependency. React Native is in the embryonic stage and all native modules are not available for direct implementations. Hence, the React Bridge Protocol exposes native code to the platform, which is a way to create custom extensions.

The future scope of this section will soon state examples of the bridge protocol for both Android and iOS.

Objects have always fascinated me and the object-centric nature of Javascript adds fuel to it. Hailing from a strictly typed language and an object oriented programming environment, careful handling of objects has always been a blessing.

Since React’s written in JSX(React-specific grammar extension to JavaScript), its fundamentals to exchange data-objects also follow a similar approach via component state and props for storage, network and similar activities.

Albeit there’s distaste to write listeners in an asynchronous programming environment, callbacks are an integral part of a developer’s codebase and since Java 8 Lambda functions have made it smoother to invoke them. I have always believed in callbacks (especially in Promises) as a rock solid concept to handle async requests with ease and comparatively with fewer lines of code. A vast number of developers initially fail to understand Promises, but, every tool can be used as a weapon only after mastering it. The APIs of React Native utilise Promises as their primary weapon to win every asynchronous war.

RESTful communications have always been laborious and writing Boilerplate code has constantly been a painful task for every native app developer. React Native leverages a Promise based Fetch API to handle RESTful activities. As the name suggests, it fetches from a source and then uses an in-built method to return a JSON object or an array of them. Such modules have facilitated developers to focus more on data than its structure.

  1. React Native is a library and not a framework. It executes a babel transpiled JS-bundle over a native platform. It’s the closest native implementation the mobile app industry has ever witnessed.
  2. React Native inflates an application to consume more storage space but as the library is still under rigorous development, improvements are being made to resolve this issue in the near future.
  3. Sometimes integrating a Third Party library is tedious and may infuriate a developer. However, the React Native CLI solves this problem effortlessly by introducing commands like react-native-link.
  4. The native-like performance of a React Native app and the ease of development is convincing the community to develop newer libraries, modules, patterns and techniques which are easily available as open source projects.
  5. There are interesting instances when apps developed on this robust platform have outperformed apps developed on any other native platform. The number of such use cases is increasing exponentially, thus, grabbing attention of many matured developers.

Tag cloud