UnBoxing React Native!

Atwoods's LawAny application that can be written in JavaScript, will eventually be written in JavaScript.

It all started with a dream of re-using engineers across platforms along with re-using code…an enticing proposition…which techie could resist that!!

Fundamentally, we wanted to have our private release trains for the micro apps which we were building within Snapdeal (better known as Services). After brainstorming for quite a while, we decided that we wanted a viable solution to the following questions:

  • How do we remove the adoption cycles altogether without duelling with play/ app store footprints?
  • How do we do staged rollouts on iOS?
  • How do we do A/B/C testing… in a jiffy?
  • How do we update our View layer on real-time basis?
  • How do we move to message driven concurrency?
  • How do we go about having predictable models and Views?

   And beyond these questions, we had a wish. We wanted to make the dev-experience so smooth that techies would like to skate on it, pun intended.

The answers to all our questions (and wish) came in a single package called React Native. We quickly adopted React (also, RN) into our tech repertoire.

Well, React Native is good. However, adopting it was challenging. We had to unlearn a lot of things in order to accommodate RN. Believe me, its easier said than done. We were faced with a host of questions and uncertainties – some easy, the others not quite so.

Our first week into React was beset with questions and doubts. I’d like to share a few bouncers we faced in powerplay:

  • How do we go about unlearning MVC and come to terms with this thing called components
  • What coding convention should we adapt?
  • Which editor should we use? (We commenced with Deco and ended up losing our code which we then re-wrote. Post this setback, we decided to go back to Atom the saver)
  • Should we structure our code by layer or feature?
  • Observables vs Promises vs callbacks
  • flux vs redux vs redux-observables
  • Reactive programming in React – RxJS?
  • Codepush vs building an in-house deployment system!
  • When do we sync/ update js bundle at the client side?
  • How do we share code between components – mixins vs composition?!
  • Maturing bridges?!?
  • Compressing and debugging js bundle?!?
  • How to tackle apk size inflation?
  • Profiling and performance?!?
  • When to say No to React?

Difficult though it was,

“Be a yardstick of quality. Some people aren’t used to an environment where excellence is expected”

Steve Jobs
With this as our yardstick, we plunged into dev, full throttle.

 In due course, flux, declarative component model, JSX, and flexbox endeared themselves to the entire team!  

We did a war-room to pack answers for all the queries we had and Unboxed React Native on SnapDeal in 31 days. On Sep 29 2016, we took the first step in moving our iOS and Android stuff to a unified repo and codebase for a cross platform solution. RN is now live on iOS for Services and we are all geared-up to unleash the magic on Android in the near future.

IMG_7549

Cheers,
Crux Tech

FacebookTwitterGoogle+Share

Tagged under: , , , ,

Back to top