React Native App logs user out when Server goes down (i.e. during development)


I’m using @spencercarli’s awesome package, and there’s one glaring issue: when you’re server goes down, like whenever you change some server code, the React Native client needs to login again before making any requests that require a userId on the server.

The package is still pretty young–but has been very useful. I’d like to figure out what the standard Meteor browser client does for this situation to add it to the React native node ddp client package we’re using. The Meteor browser client must either detect the disconnection and after reconnection make another request to log you in with your token (which also seems incorrect), or it must somehow remember better.

If you look in the code of node-ddp-client you will see there it doesn’t store the login token. I’m actually using @spencercarli’s React Native Meteor Boilerplate package: which adds additional code specific to React Native to store the login token in AsyncStorage. What I’m thinking is the ddp client for standard browser-based Meteor apps must store this token or perhaps another type of token so that it can continue to make requests to the server when it comes back on. Because the way this seems to be working is that it logs you in with your token and then opens a websocket connection, and then that websocket connection must simply stay open. There is no state–i.e. a token–maintained on both the server and client that stay alive through temporary outages. The login token I mentioned before seems to be used simply to initiate the connection, but then once the connection occurs, it’s on its own. So there must be something missing that the browser client uses to overcome these situations. Perhaps it’s as simple as detecting a disconnect and re-logging you in with a token, and therefore re-opening the websocket connection. If that’s the case, does anyone have an idea where the standard browser code that does this is?

Any tips–however small–would be much appreciated.


Perhaps it’s as simple as detecting a disconnect and re-logging you in with a token, and therefore re-opening the websocket connection.

I think that’s exactly what Meteor does on the client. This is something missing from the boilerplate.

I can’t point you to exactly where this logic lives but I imagine it’s somwhere in the ddp-client package.

Do you know if this is also an issue in react-native-meteor?


it looks like they solved just as the first option above was described:

So I think node-ddp-client reconnects, but unlike theirs, it doesn’t attempt to load the initial user from a token. I guess that’s easy enough to add. But now you got me wondering if I should just use react-native-meteor. I’ve been comparing what they’re doing and what they are not doing that node-ddp-client is and vice versa. I do feel like the core Meteor DDP stuff would be nice abstracted out of it though. Or maybe in my case I just load up everything they have whether I use it or not, and voila.

Either way, since React Native is without a doubt the way forward for mobile development, it’s important we coalesce around one main package that bridge’s Meteor and React Native. And from that perspective, a “family” of packages is fine, i.e. if ultimately we abstract the their DDP stuff into its own package. But for now I’m going to add the re-login functionality to your package. …I’m surprised there are so few people working with React Native + Meteor. There isn’t that much that needs to be done here–it just needs to be done extremely solidly and dependably.


@spencercarli well, I solved it in a non-abstracted way for my particular app:

connectPromise(reconnectCallback) {
    return new Promise((resolve, reject) => {
      this.connect((error, wasReconnect) => {
        if(error) {
        } else {
          if(wasReconnect && reconnectCallback) {
            reconnectCallback(); //callback must be used for reconnections since Promises can't resolve more than once

So obviously reconnectCallback logs the user in again with a token from React Native’s AsyncStorage. It makes use of code that already existed in node-ddp-client to specify a callback to connect which is also used on reconnections. However, it’s specific to my app, not abstracted as a built-in feature of node-ddp-client.

It should be easy to put the code back into node-ddp-client–the only thing is I have a few promise-based things I’m doing in my actions that at the moment I’m not sure how to address by interfacing into a node-ddp-client abstraction that re-logs in for you. Perhaps nothing is needed but to re-open the authenticated socket connection in this way.


I definitely agree with this. I think that putting a combined effort behind react-native-meteor is the best option right now. There’s a lot of work behind it already, more complete API, and it handles more edge cases.

I would love to see it eventually broken into multiple packages so we can pick and choose but I think right now it works to just use what you need. I’m taking that path right now - I store data in redux but I love having all the “normal” meteor api there for me to use when I need it.