Application Structure

guide
22

Hi!

Having trouble understanding how to use modules with ‘package-only’ type application structure.

I’m working on an app with the following structure:

/app
  /packages
    /foo
    /bar

I was following this structure to create flexibility, because I want to isolate features into packages (allows me to plug and play features by importing a package)

The problem I’m having is when trying to import/export between the packages foo and bar. Let’s say I have an exported function called baz() that is implemented in the ‘bar’ package, and I wanted to import that in the ‘foo’ package - I’m not entirely sure where to do this, or if I should abandon the package-structure totally and switch to modules.

23

I would consider it, I’m not sure there’s much benefit in packages for their own sake any more.

Did you try import { baz } from 'meteor/bar'?

24

Thanks for the reply!

Yeah, I tried that. I’m not sure there is a case which we can import a package from Atmosphere vs a local package.

Leaning towards switching to module structure completely, since that’s going to be the new convention.

25

I’m not sure what you mean here, but perhaps you forgot to api.use('bar') in foo?

26

Sorry,

I tried that before. Wasn’t working either. Foo threw a ‘bar not defined’ error. It’s all good, currently switching to modules. Thanks so much!

1 Like
27

Another question, I’m having some trouble understanding importing from Atmosphere packages.

let’s say I want to use SimpleSchema from aldeed:collection2 - how do I know what to import from aldeed:collection2?

import {SimpleSchema} from 'meteor/aldeed:collection2'

is this correct? what if I wanted to import other things from the aldeed:collection2 package?

28

In the same way as you’d know what symbols it auto-exported in the old world (in truth, no good way apart from documentation or inspecting the package source or futzing around on the console).

You can import multiple things with that syntax:

import { A, B, C } from 'meteor/foo';
1 Like
29

Okay great, thanks so much for you help. Time to start reading through the source :grinning:

30

There is one other way to be able to quickly tell what you can import from an Atmosphere package. After you’ve added the package to your project, open that packages source file from within your local app. For example, to see your import options for jquery, open the following file:

[app_root]/.meteor/local/build/programs/web.browser/packages/jquery.js

Scroll right to bottom and you’ll see your available import options in the exports section:

/* Exports */
if (typeof Package === 'undefined') Package = {}; 
(function (pkg, symbols) {
  for (var s in symbols)
    (s in pkg) || (pkg[s] = symbols[s]);
})(Package.jquery = exports, {
  $: $, 
  jQuery: jQuery
});

So from this we know we can use one of:

import { $ } from 'meteor/jquery';
import { jQuery } from 'meteor/jquery';
1 Like
31

Another way is (in the browser console or the shell):

require = Package['modules'].meteorInstall();
exports = require('meteor/X')

and take a look

2 Likes
32

Great - here’s one more (to keep the typing even shorter :slight_smile: ). Just dump Package in your browser console:

779×309 44.6 KB

7 Likes
33

Hi guys,

I’d love to only load the full application code for logged in users.

How would this work using modules? What pattern do you recon?

34

Meteor 1.3 still does not support code splitting so you need two apps. You can still share component code, a server, and login credentials across two apps. See the Meteor Guide for some ideas.

35

I am new to meteor, the one problem every newbie faces is when he sees so many options to follow, please suggest should I follow the meteor guide for application architecture/structure or MANTRA from KADIRA.:innocent:

36

My opinion is if you don’t know how to answer that question your best approach is the Meteor Guide.

1 Like
37

Thanks… going forward with the suggestion.

1 Like
38

hello!
we have two variant how we can add our stylesheet in app:
the first way is automatically include by meteor’s system
the another way is to add a stylesheet to our app by “import” (es6).
In the first way, a style will include in .
In the second way, a style will be added in the tag (), but as far as I know, in this case the stylesheet don’t cached.
A what way better?
thanks in advance.

39

With 1.3.2.x getting a few releases here and there, I would opt to just put the minified version of the one you are using in public and refer to it from there from index.html. I downgraded to 1.3.1 for the time being because it seems to have become the recommended version again and that does not have import css support.

Custom CSSes I would still put in client and let Meteor run with it.

My main driving force at the moment is predictability.

40

Maybe I missed something, but shouldn’t the UI folder be under a client folder? That doesn’t apply to or affect import/export, but if using webpack:webpack (or any other form of Webpack), or Meteor HMR, won’t not having the components in a client folder force a server rebuild every file change - thus negating any fast reload capability?

It seems like UI and any other client specific stuff should be in imports/client - no?

2 Likes
41

Hi, with this structure, that works good for me, it took me 2 days to understand a behavior I wasn’t expecting, this is my app structure:

imports/api
– items.js
– data.js
– security.js
…

Within security.js I define my collections that I then import in item.js OR data.js with
import { UsersData } from '../api/security.js';

The problem is when you wanna import the same collection in BOTH, in this case a publication/subscription would work only in one of them (I guess the first loaded). So I can write the pub (e.g. in item.js)but it is never reached by the client. When I move it to data.js it works…
–> is this a normal behavior?

Thanks a lot :grin: