Using the share Object with CoffeeScript

[Roman Kuba]

Hi,

I started to playing around with Meteor and tried to do every line of JS in CoffeeScript.

This turns out to be a minor problem, even with the `share` Object available.

For example if I create a new collection called `Posts` I would do following:

```

share.Posts = new Mongo.Collection('posts')

```

I could also access it in other coffee files but its not useable from the browser console for example.

```

share.Posts.find() 

```

would work in a script but not from the console. Also using it without share.

If I create it as a js file without share. Then I can use it anywhere.

Also in other Coffee files without share its useable and everything. 

So the key essence is, as long as the main collection file is initaited in a JS file it works fine.

So what I would maybe like more would be something like:

```

@export Posts = new Mongo.Collection 'posts'

```

How would you like that ? 

Best,

Roman

[Daniel Dornhardt - Daniel Dornhardt Development]

I agree it's not optimal, but the workaround I'm using seems clean enough:

- I create a JS object in a file named lib/00_namespace.js . In there I declare a global object for the app I'm building. For "Example App" it could be "EA" or something.

I add global helpers to this dict - and I actually declare the object keys i'm gonna be using to have the "namespace" contents explicitly declared and documented there as well.

EG:

/**

 * Example App Master Namespace

 */

EA = {

  // popup helper (added later in code)

  popup: undefined

  // global helper functions

  helpers: undefined

}

---

etc.

Also I actually, because I'm lazy, I put Classes/Types I am using throughout the project in the global namespace with the same prefix, although lowercased, and I put my collections in the global namespace via Coffeescript as well, because they're just too damn useful. I should probably namespace/prefix them as well, I know, but I don't yet - at least not in my current project, maybe in the future.

EG. I do 

In notificationMessage.class.litcoffee I do:

    class @NotificationMessage

      constructor: (doc) ->

        _.extend @, doc

In notificationMessages.litcoffee I do:

    @NotificationMessages = new Meteor.Collection "notification_messages",

      transform: (doc) ->

        return new NotificationMessage doc

So I have both NotificationMessage and NotificationMessages available in the global namespaces / objects on both the client and the server.

Note that you can use both NotificationMessage and NotificationMessages without the "@" - prefix as soon as they are available in the "global" context, and that's what I do, even in the same file after defining them.

It's not super-Clean, but I guess if you'd use eaNotificationMessage and eaNotificationMessages instead you could say it's good enough :)

Pro-Tipp I figured out some time ago: Put as much helpers as you can on model objects as shown above, that way you can avoid writing a lot of template helpers while keeping the code clean too. Also IronRouter - Controller - Helpers, but Model Objects can get you far indeed.

There were some more ideas on this in the context of package-only-development, which I moved away from because it was quite a lot to juggle and which would tend to break a lot / was slow for me, and which I can't find anymore right now anyways. Best thing to keep in mind is creating a global object in JS and then grouping everything in there yourself.

Best wishes

Daniel

Daniel Dornhardt, Daniel Dornhardt Development

dan...@dornhardt.com

+49 152 - 56 17 22 61

--
You received this message because you are subscribed to the Google Groups "meteor-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-core...@googlegroups.com.
To post to this group, send email to meteo...@googlegroups.com.
Visit this group at http://groups.google.com/group/meteor-core.
To view this discussion on the web visit https://groups.google.com/d/msgid/meteor-core/3190b94a-28d0-43fe-b056-5e6ca0f1ce62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Mao]

Inside packages, you can use api.export to get variables automatically into the context of files.