A modest extention to React Native Web with immodest ambitions.

If you didn’t know, there is a tool set which takes your React Native code, and puts it back into html browser format. In other words, your source code uses <View> and <Text> instead of <div> and <p>, and then the tool stack converts your JSX back to browser for the web.

There is React Native Web, and React Universal – they both work surprisingly well ! I’ve got a previous post on React Universal here.

How about if we took this one step further ? What if we took our React Native Web code, and wrapped it inside a transparent phone mockup PNG ? What if we had different phone options, and we were able to convert the display size to give a reasonable approximation of how the app would actually look on a phone ?

Hold on, now we’ve got react native –> browser –> back to native again ?? What is this madness ?

Ladies and gentlemen, I present to you … React Hydrazine.

Why God Why

React Native has hot code reloading, and it is a Good Thing. However browser-based hot reloads are potentially even better. The reloading is incrementally faster, you don’t have to run a simulator or emulator, and in my experience, Android emulators can be pretty demanding of resources.

Being able to debug JS, layout and logging problems in a full-size browser gives us all the browser tools, making development potentially faster as well.

But as I’ve been plinking around, it’s starting to go deeper. Take a step back and think on it … what does it mean to have a mockup of a mobile app, on a website, running live code, which is your actual business and presentation logic ? Think of this in an Agile “showcase” iteratation cycle … it gets pretty impressive pretty quickly:

Product manager requests a change
Dev makes the change and commits
CI picks up the change, builds and auto-deploys to a “branch-tip” environment

Now the PM can see the change within what … 3-5 minutes ? No emails, no native build compilation times, no mobile installation.

Implications for testing

Let’s unravel this sweater some more, because this potentially means a lot for testing.

First of all, the automation stack for web is less complicated, more mature, more manageable than automating mobile. Selenium is simpler than Appium, and for our purposes we can ignore cross-brower compatibility testing, so one browser is much simpler than two native platforms. Of course we’re not saying abandon your mobile testing; that would be stupid. But this is pretty strong augmentation to your test stack:

You can frontload a lot of your automated tests at the browser stage.
Browser automation is going to run a lot faster than mobile tests.
You have all the browser contextual tools for reporting and debugging.

This is potentially similar to how automated API testing is a great insulator for mobile test stacks. Problems in the API can cause unpredictable errors in the app, but when you catch them at the API layer, the issue is much more determinstic and straightforward to isolate and resolve. It’s a similar paradigm, then, if we putting mobile code in a browser, then run browser automation against the app. We’ve now isolated business and presentation logic away from potential platform issues. Debugging issues is correspondingly simpler – a sort of “middle ground” between the raw data of the API layer, and the hurly-burly of the full platform environment.

API tests, followed by browser Hydrazine tests, each of these two finding issues in a reduced-complexity environment, before a final platform suite. A “multi-pass” testing system, three robust layers of testing, each layer insulating and complementing the next.

Now that is some thorough automated testing !