Sending a string from the server to the client

help
1

I’m wrapping a npm module that allows users to sign up with a specific oauth system. This package works and I’m using it in an Express app.

The npm package is loaded on the server. There is a method that returns the url to redirect the user, in order to authorise de application. Now, I need to send this string to the client, in order to use it on the OAuth.launchLogin.

I don’t want to save it on the database. And I can’t load the npm module on the client. And I don’t want to hardcode the url on the client like the core methods.

Does anyone have an idea? Am I using the wrong approach?

2

Gabriel,

You might be able to use https://github.com/meteorhacks/meteor-inject-initial to inject your own code in the raw server output, maybe in the HEAD tag. I believe that the Meteor OAuth package does something similar where it renders a hard-coded string to get it on the client, and then immediately does a Javascript reload.

HTH,
Gerard

3

In Meteor, you send data from server to client using the publication/subscription system. Mongo collections are used to store data, so if you use Mongo on the server, it’s persistent, but you can also just use a minimongo store defined on the client and it will only exist in memory for each session.

Here’s how to do it:

if (Meteor.isClient) {
  var myTempCollection = new Mongo.Collection("myStringCollection");
  Meteor.subscribe("myString");
  Template.myString.helpers({
    myString: function() {
      return myTempCollection.findOne().myString;
    }
  });
}
if (Meteor.isServer) {
  Meteor.publish("myString", function() {
    // don't return a cursor from a database, just tell DDP to add your string to the publication and send that
    this.added("myStringCollection", null, {myString: "herpderp"});
  });
}
8 Likes
4

Nice, Rahul!

That little code snippet has some really valuable concepts in it.

5

I had already considered this option, and it’s a really good idea, but I still have the feeling that there should be a more natural way. Either way, thank you for the answer.

6

I didn’t know about this package, and it’s a really good idea. The problem here is that I don’t know the redirect uri by the time the server sends the html, for that reason I can’t really use this. Thank you.

7

This is the most “natural” way to do things in the Meteor platform; DDP is the standard for exchanging data now, as opposed to HTTP or XHR.

If you’re still not satisfied, can you try describing your ideal solution?

8

The issue for me is not ddp, it’s the publish/subscribe. Now that you’re asking for my ideal solution I guess it would be to have a shared variable (something like Session, but shared between the server and client), where I could change set a value on the server and have it on the client.

I understand that we can create an abstraction on top of the publish/subscribe for this, I was trying to find if there is already something to deal with this.

9

How about using a method? Still uses DDP, but instead of manually using pubsub, we use the ability to request data:

if (Meteor.isClient) {
  Session.setDefault("myString", null);
  Meteor.call("getMyString", function(err, res) {
    Session.set("myString", res);
  });
}
if (Meteor.isServer) {
  Meteor.methods({ 
    getMyString: function() {
      return "herpderp";
    }
  });
}
1 Like
10

I had also thought about that, but at the time it wasn’t an options since that doesn’t work when you need to make async operations on the server, but in combination with this it’s a really good solution. I think I’ll go with this one. Btw, thank you for taking the time to answer me.

11

I don’t understand. Why do you need this extra ‘promise’ package to get the data to return in this code? If it’s being retrieved in a callback, shouldn’t that work whether it’s asynchronous or not?