Last updated May 24, 2016
There are a few questions that I see pop up on the various blog posts I've written on React Native Meteor. I want to put together an FAQ to, hopefully, help you out and point you in the right direction. This document will be updated over time so please send me anything you feel should be included.
Make sure to point your React Native app to the correct url for your Meteor app
Meteor automatically knows what your server URL is because it handles the entire stack. Since React Native is purely a client and doesn't have those built-in server bindings you need to inform it of which server you want to connect to, and change it based on the environment. This will likely be localhost:3000 in development and something like wss://my-fake-app.meteor.com in production. Make sure you're connecting to the correct one before publishing and when debugging.
When I try to `subscribe` I get an error of `INVALIDSTATEERR`, what does this mean?
This error means you're trying to interact with the DDP/Meteor server before you've actually connected to the server. Make sure that you point to the correct URL of your Meteor server and that you're connection has succeeded before making calls/subscriptions.
How can I identify a user?
If you've authenticated your user via DDP then you'll have access to this.userId in publish functions and Meteor.userId() everywhere else. Here's a few articles on authentication with React Native and Meteor
Can I do Hot Code Push?
If you want to get CodePush integrated check out this article.
You only have to connect to the DDP (Meteor) server once
This one may seem obvious to some of you but for those just getting started know that you only have to connect to the Meteor server once, likely when your app first mounts. Subsequent calls and _subscribe_s will use the existing DDP connection - you don't need to specify a new one prior.
Which DDP Package should I use? Why?
This is a tricky one because there are a few options out there currently. Here are a few:
- react-native-meteor: This is the one I’m really excited about and have been putting some effort behind. It’s a “magic included” DDP client — allowing you to use an extremely similar API to what you may be used to with vanilla Meteor. It’s still a work in progress but should definitely stay on your radar.
- asteroid: I haven’t personally used this one but it is popular for people who want to use Meteor as a backend but have more freedom for how they build the front end of their app.
- ddp.js: This is a good one if you want a very raw ddp connection. It’s actually the one that backs react-native-meteor and asteroid.
- node-ddp-client: This is a stop-gap solution to fix some of the issues with ddp-client that I mention below. It fixes a few bugs, corrects documentation, BUT doesn't use minimongo-cache
- ddp-client: This is the one I’ve used for quite a while. The latest version uses minimongo-cache. Downsides include a few bugs, incorrect documentation, and it’s no longer supported.
What about Minimongo?
There are some efforts to replicate minimongo without the browser dependency but I, to be honest, haven't followed it too much as I've preferred to not use it in React Native. The leading contender for a replacement is minimongo-cache. It's also been integrated into react-native-meteor so my opinions on minimongo in React Native may change soon!
Be more conscious of your API and data schema up front - it's harder to update things even with CodePush
When you're developing with Meteor, or the web in general, you've got quite a bit of flexibility. You can publish new features and bug fixes whenever you want and know that the user will have the latest code in their hand the next time they visit your site. The same isn't true for mobile app development - this goes for Objective C, Swift, Java, React Native, etc. You've got to go through some sort of process to update your code... and then you need your user to opt in to updating.
This has gotten easier with the likes of CodePush and AppHub but it's still something to be aware of when developing for React Native. Make sure that you put some time up front designing your data structure and API so that it doesn't bite you later.
Consider Reactivity Carefully
One of the great things about Meteor is the reactivity that’s built right in. This reactivity is great but needs a constant DDP connection to work, when building an app it’s possibly/likely that your user will lose their connection at some point. With that, when you don’t need reactivity I would highly suggest using a Meteor method over pub/sub for things that don’t need to be reactive.
What about OAuth?
This has been the most requested item... and I've found it to be tough. The existing "magic" OAuth that comes with Meteor doesn't play too well with an external client's OAuth process due to its tight coupling with the browser. I have dived into it a bit and put together a guide for the Google OAuth process here:
Do you want me to write a definitive guide on React Native Meteor OAuth with the various OAuth providers? Ping me on Twitter.
Boilerplates are a great way to get that instant gratification. You may grow out of them later but when you're learning they're extremely valuable and get you a quick win. Here are a few
- react-native-meteor: This is one I wrote and thus am partial to. It‘s somewhat opinionated and lets you dive right into building your app rather than handling all the behind the scenes stuff. It also demonstrates some good practices.
- react-native-meteor-starter: A bit more in depth than the other but shows you more functionality.
If you have any questions just respond to one of my newsletter emails and I’ll answer it the best I can. You can also ask me on Twitter.