search

oortcloud / unofficial-meteor-faq

The unofficial Meteor FAQ
953 stars 94 forks source link

Default app structure #57

Open grabbou opened 10 years ago

grabbou commented 10 years ago

Any concerns / updates after few months? I am currently developing application, where I moved Meteor.methods to server/methods, instead of handling them in libs, so no need to check whether we are in client or server environment. For bigger applications, it might be useful.

Also, maybe we can mention something about creating namespace.js file, where we can declare our "global" placeholders, so that in other parts we can easily use 'use strict'?

If you are open to any kind of discussion on that - let me know. I can share my thoughts on that and I am looking forward to hearing your opinion, as it's always good to discuss your approach with somebody else!

PS. FAQ is great for new-comers!

tmeasday commented 10 years ago

Hey @grabbou

I definitely still put methods in a global directory, although it is true that some methods are better placed directly in server/ as they'll never run on the client.

I'm not sure about the namespace file -- can you elaborate further on the use strict?

grabbou commented 10 years ago

Hey, yep.

Basically, I follow the package-only pattern (months ago when I started I've been reading article about that saying BTW 'although it's not recommended pattern in Unofficial Meteor FAQ :+1: ), but basically, the idea is to have one file (loaded before any other file from your system), that defines your global variables, like: Utils = {} and so on.

Then, in the rest of your files, you can freely use strict mode and refer to already created global variables.

It's quite good in terms of having multiple packages as you can easily manage dependencies (e.g. package app-utils exports AppUtils object with different utils. Having it exported instead of globally included helps to manage dependenies).

I hope that's clear enough :dart: