0

If I write a plugin which requires a very large initialization (14 mb JavaScript which takes 1 minute to set itself up), how can I make this object persistent (for lack of a better word) across the JavaScript files used in a Meteor projects?

After the initialization of the plugin, I have an object LargeObject and when I add a file simple_todo.js, I want to use LargeObject without it taking a minute to load after EVERY change.

I cannot find any solution.

I tried making a separate package to store this in Package object, but that is cleared after every change and reinitialized.

What would be the proper way of doing that? I imagine there should be something internal in Meteor which survives hot code push.

MasterAM
  • 16,283
  • 6
  • 45
  • 66
CharlesS
  • 1,563
  • 2
  • 18
  • 31
  • Poor wording! You don't want something _static_ (which is an OOP term), but something _persistent_ across multiple code changes. Also, please add the following information: Is your object generation taking long because of **data** generation (fields like strings, numbers, ...) or because it has to generate **methods**? If it only takes long to generate data, you could JSON it. – Kyll Jun 26 '15 at 09:59
  • I said for lack of better words (I am from a Java background); a static var in fact does what I want. Hence that choice of words. – CharlesS Jun 26 '15 at 10:10
  • And it takes long because it needs to initialise a lot of things (which, by rewriting all the included libraries to support that, could be optimised, but that seems a slight bit crazy). One of the things it does is setup connections and exchanging data (which changes per connect) which I have no control over. So I really cannot optimise those parts. – CharlesS Jun 26 '15 at 10:12
  • ... What? A static variable is just a class variable, it has nothing to do with computations or generation. What you want, unless I'm highly mistaken, is to avoid repeating some heavy computation on each server reload. And that's why I suggested taking the object, JSON-ing it, and working on the JSONed version (even if it's outdated). – Kyll Jun 26 '15 at 10:14
  • In Java if I do class Bla { static LargeObject x = null; Bla() { if ( x==null) x = LargeObject.initForAMinute(); } } I have what I want. That x will contain my initialised object. As a Singleton; I could make a pool of them if needed etc. – CharlesS Jun 26 '15 at 10:14
  • So you are saying that there is nothing 'low level' in Meteor which doesn't get refreshed when reloading files? And I just should make workarounds because of that? – CharlesS Jun 26 '15 at 10:17
  • Can't you just save the object to localstorage? It's not 'internal' to Meteor per se but it is used by meteor for stuff like saving the 'sessionId' (for persistent login). `localStorage.setItem("myLargeObject", myLargeObject);` then later on `localStorage.getItem("myLargeObject");` – Michael Mason Jun 26 '15 at 12:30

1 Answers1

0

Here are two possible solutions I:

  • Cache some of its properties inside Session
  • Cache some of its properties inside a simple collection
  • Use a stub in your local environment.

Session can only be used client side. You can use a collection anywhere.

Session

client

example = function () {
  if(!(this.aLotOfData = Session.get('aLotOfData'))) {
    this.aLotOfData = computeALotOfData()
    Session.set('aLotOfData', this.aLotOfData)
  }
}

Here, no data has to be transferred between client and server. For every new client that connects, the code is rerun.

Collection

lib

MuchDataCollection = new Mongo.Collection('MuchDataCollection')

server

Meteor.publish('MuchData', function (query) {
  return MuchDataCollection.find(query)
})

server

example = function () {
  if(
    !this.aLotOfData = MuchDataCollection.findOne({
      name: 'aLotOfData'
    }).data
  ) {
    this.aLotOfData = computeALotOfData()
    MuchDataCollection.insert({
      name: 'aLotOfData',
      data: this.aLotOfData
    })
  }
}

Even dough you can access the collection anywhere, you don't want anyone to be able to make changes to it. Because all clients share the same collection. Collections are cached client side. Read this for more info.

Stub

A stub is probably the easiest to implement. But it's the worst solution. You'll probably have to use a settings variable and still end up having the code for the stub inside the production environment.

What to choose

It depends on your exact use-case. If the contents of the object depend on the client or user, it's probably best to use a session-var. If it doesn't go for a collection. You'll probably need to build some cache-invalidation mechanisms, but I'd say, it's worth it.

halbgut
  • 2,368
  • 17
  • 22