Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default app structure #57

Open
grabbou opened this issue Aug 2, 2014 · 2 comments
Open

Default app structure #57

grabbou opened this issue Aug 2, 2014 · 2 comments

Comments

@grabbou
Copy link
Contributor

grabbou commented Aug 2, 2014

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
Copy link
Member

tmeasday commented Aug 6, 2014

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
Copy link
Contributor Author

grabbou commented Aug 6, 2014

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 👍 ), 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 🎯

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants