For close to two months now I’ve been working nearly exclusively with React Native. We use Meteor at Differential to build powerful web and mobile apps but most of these mobile apps are Cordova.
However, due to the needs of our client a hybrid app wasn’t going to suffice so we started exploring the possibilities and decided to move forward with React Native – both our team and theirs have a lot of experience with Javascript so it made sense.
The experience has been enlightening, I personally have been working with Meteor exclusively for 3 years, so I haven’t had too much exposure to the greater Javascript community. This was a great time to learn some new tools.
The process has been extremely interesting, full of ups and downs and new challenges daily. I wanted to walk through some of the challenges I’ve found, coming from a Meteor background, while working with React Native.
Challenge #1: No more user accounts
Meteor has a strong accounts system system built into the platform. On both the client and the server. Unfortunately, we don’t have that convenience in React Native.
If you’re used to using Meteor.user() to determine what screen to show a user in your web app, you’ll have to do some new thinking on your React Native app. I struggled with this at first, Meteor had just made it so easy, but it’s not too hard to do once you let go of the ease that Meteor.user() brings.
The same goes for the other conveniences that Meteor’s account system provides, they just don’t exist in React Native, so you’ve got to roll your own.
To accomplish this we’re using React Native’s AsyncStorage (which serves the same purpose as localStorage)
Challenge #2: No out of the box data reactivity
Meteor.user(), CollectionName.find(), CollectionName.findOne() are all reactive data sources in Meteor. You don’t have to do anything special to set that reactivity up – it just works out of the box. It’s a great experience…
but it doesn’t work out of the box in React Native. You’ve got to listen to events in the React Native app and handle your own reactivity. Again, once you get past just how easy it was while working in Meteor, you can roll your own implementation and it works.
Compared to Meteor there are just a few more steps involved. Not only do we have to subscribe but also how to listen and react to changes in data.
Challenge #3: Data Interaction
This experience has gotten much easier since my original draft of this post. We’re usingHarrison Harnisch’s node-ddp-client npm package to handle our DDP connection. Behind the scenes it’s using minimongo-cache to manage the collections. This provides a similar experience to that of Minimongo that comes with Meteor.
Like I said before, you have to roll your own reactivity, but at least you can use very similar (or the same) queries on both the client and server. We’ve found this to work for our needs so far.
Side note: Checkout out Harrison’s lighting talk where he covers the ddp-clientpackage. He’s also got a repo that serves as a good starting point.
Learning from Example
I learn best by seeing real world examples so I wanted to provide a resource that could serve as an example for how we’re working through the challenges I outlined above.
I’m working on a project to match the Meteor Todos Example one to one in features in React Native so you can compare what writing a React Native app looks like with anearly stock Meteor app. The React Native app communicates via DDP with the web app and has (eventually) all the same functionality.
I encourage you to check it out, fork it, and play around with it. Let me know what your thoughts are and ways I could improve things – I’m certainly still figuring this all out.
Here’s the repo: https://github.com/spencercarli/meteor-todos-react-native-2
