So, last Friday night, I decided to turn my infrastructure into code by learning Ansible, and capture the entire demo configuration, so that, in...
You are here
The thinking behind React Native for a new Mobile App
The development of Opsview Monitor’s new Mobile App opened up the potential to utilize a host of new platforms for the breakthrough app. Front-end developer Rob Calcroft details his experiences of the foray into React Native.
Where we started
Previously, through study, I'd spent a fair amount of time hacking around with React, so when a mobile app project came up at Opsview I was quick to add React's native friend into the list of potential solutions. After reviewing a number of solutions including Ionic, ExtJS 6, (our current front-end solution) and *real* native, we quickly discovered that React Native ticked all the boxes we were looking for. With React we benefitted from:
- A cross platform
- The ability to send mobile notifications easily
- It’s performant - It compiles to native platform code which gives it a huge performance boosts over things like hybrid apps which sometimes struggle to get 60fps on mobile
- Good speed of development i.e. time to MVP
- No huge skill-set change for the front-end team
- A solid roadmap
As an aside
Before I go further it's worthwhile noting an omission some readers may have noticed from our list of potential solutions. This is a progressive web app. This was something I would have loved to have looked into, however we were constrained by the lack of mobile support for many of the great technologies associated with PWAs. ServiceWorkers (for offline and background sync), HTTP/2, and Web Notifications were regrettably not an option as we were purely focused on mobile and not desktop (we already had a client) so this quickly became apparent it was not a feasible option.
Additionally a hosted PWA solution would require a lot of infrastructure implementations that we don't as yet have available. It is definitely something I would like to prototype and add to Opsview Monitor in the future.
Back to the task at hand - React
After selecting React Native I spent a good week developing and iterating the current prototype; investigating deployment practices and more advanced features.
When the groundwork started, I found that the initial prototype was so strong that I could iterate that project into what became the `master` branch.
During the initial stages of development I learned a lot about mobile UX and its stark differences and requirements vs desktop. From ensuring every user interaction has meaningful visual feedback, to refining the user journeys continuously as we alpha tested and found patterns and journeys users had that were not quite what we expected. This real user testing (along with real device testing) shaped the very nature and experience of the app. It was very much user driven.
On the technical side, it was great to be able to apply my React knowledge to a new and large project. I took some time to learn more about React app structure and made the mistake that I thought I wasn't going to make: implementing Redux.
Bumps in the road
The Redux mistake was a particularly annoying one to make as I had read why I might not need Redux but stubbornly went ahead and used it. It did offer some very clean looking code, and gave us the option to use time travel debugging (something I never ended up using!), but in the end I found Redux blocking me effectively reusing large components that I'd built, as they ended up using the shared component state. It blocked me so much and my workarounds failed, so I decided to just rip out Redux altogether. This actually really helped; new features didn't require touching 3 files and it forced me to localise and refine my component state trees.
Back on topic and focussing on React one of the neat, somewhat hidden benefits is the component based nature of React. There is a fantastic community of component developers, of which I am now a part, who create and share a lot of really useful components that allowed me to quickly develop features and save myself from re-inventing the wheel for some of the basics such as collapsible components or navigation.
I'm now squirreling away at a lot of really cool features that I hope users are going to love. However I'm not out of the water yet; I still have some big challenges ahead such as preparing the app for production, shipping betas, adding continuous integration and then actually shipping to production.
I'll be sure to report back on how we get on with that in part 2!
More like this
Whether you prefer Ubuntu, Centos or RHEL, monitoring the performance of your Linux hosts in the public cloud is not as straightforward as it...
Kubernetes’ extraordinary resilience tends to change the emphasis of monitoring from alerting to resource and performance management.