Application Structure

guide
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:

42

Hi guys,

just letting you know that I stumbled upon a use-case where I need to FORCE a REAL RELOAD when using require() (without using the require-cache).

I have NOT found a solution how to achieve this in meteor and opened this topic [solved] How to force ``require-reload`` when using ``require``?.

Maybe anyone has an idea how to do this?

43

“Meteor 1.3 Application Structure for Dummies”

Hi Guys,

I guess that’s what best describe my doubts:

  1. The guide says: “it is recommended that you write your application to use ES2015… provide backwards compatibility with applications written for Meteor 1.2 and earlier”. Does it means eager loading will eventually be deprecated? Should I hurry?
  2. The guide says “You may combine both eager loading and lazy loading using import in a single app”. What happens to Atmosphere packages added by Meteor add <package> and go inside .Meteor folder, not imports? When do I need to import them on my code, when I don’t?
  3. If I declare importing one atmosphere package, what happens with the load order of the rest of the undeclared ones? Is it a declare all packages or none deal?
  4. Do I have to declare import on all NPM packages? If I choose to work with the eager loading path only, how would that works?
  5. The Guide mentions the “Load order”, but they are actually all loaded at the same time as all files are minified and gziped into one single .js, .css. html files, etc… Are there plans to actually splitting code and load on client only as needed?
  6. Is it mandatory to declare import { Meteor } from 'meteor/meteor' ? If so, where is the best possible place? What would one gain / loose by declaring it later in the application?
  7. import surely means a lot for larger projects with larger teams. I understand that this is because it helps modularizing the application and avoid crowding Global space into a messy thing. It also replaces the not so elegant lib folder and file naming schemes to assure code dependency order. But for smaller teams / projects, what other benefits can one expect? Improved app / load speed? Would the extra complexity pay off? Can we justify it?
44

I will let someone more experienced amswer your questions as I’m also trying to grasp this, but using module imports is entirely optional at this time. You can still use the old way if you prefer. Touching on you last question, it may even be the preferred way for small projects, depending on your requirements.

Like you said, there is currently no lazy loading or code splitting, since everything is compiled to a single file. At least that’s my understanding.

1 Like
45

@tmeasday not really ground breaking but where would you suggest to put some basic html files that aren’t really ui like a simple head.html containing the <head> head tag as it grows in an application? Directly inside the /client/head.html

edit: i assume my guess to be right looking at this commit:

46

Hello all,

It would be a really nice addition to make an alternative application structure recommendation for large projects suggesting package-esq structure. Like what is being done at https://github.com/TelescopeJS/Telescope

There are many articles out there with some very neat ideas,

Why?

  • Such structures go very well with Functional Programming paradigms
  • It especially plays well with React-Redux applications
  • The idea is to have each package do one thing, and one thing only
  • Each package is a complete mini-application in and of itself
  • It makes debugging large applications a breeze
  • The folders are very well organised
  • There is a very clean chain of dependencies, thus dependency management is very easy

I can take up writing this part if MDG is okay with it.

Best

47

Would this be Meteor packages or npm packages?

Understanding the best way to structure a large app with npm packages (modules) would definitely be worth publishing.

48

Both. There would be NPM packages as well as Meteor packages.

Have a look at < https://github.com/TelescopeJS/Telescope > for example. This is a very good way to structure a large app. Other large apps can be structured in a similar way.

More precisely, look at - https://gist.github.com/SachaG/f22e04bf91751435806d. Meteor packages can be managed like that.

And, NPM packages are installed globally in the usual way. See https://github.com/TelescopeJS/Telescope/blob/master/package.json for instance

49

You misunderstand. I’m very familiar with that approach - and most Meteor devs involved in large app development probably are too. However, imagine a world with no atmosphere or Meteor package manager. How would we go about writing a package structured app where current “local” packages are not Meteor packages, but npm modules.

So, more:

  • how to write npm modules
  • how to manage dependencies
  • how to have local (private) modules
  • etc.

Like it or not, the fact is that MDG are becoming more mainstream JS - and that means npm. I don’t expect the Meteor package manager to disappear overnight, but npm is clearly the way we’re being steered - and that’s also the direction most “traditional” Meteor devs are least comfortable with.

I’d considered writing something for this myself, but I’m currently too involved with project work to devote much time to it.

4 Likes
50

Hmmm, that’s a good one. How would you about doing that? Do you have any example project that uses this kind of setup?

51

And therein lies the problem opportunity. :wink:

My idea was to develop the documentation while building the app. As I say - not enough hours in the day atm.

52

I tried looking into doing that myself, I had it to a point but then I realize it isn’t worth it unless the a submodule itself is packageable.

The main reason was we now have import and that allows us to pick and choose which parts we would want in the application to load given the scope (using eslint). In the older versions of Meteor everything was loaded and packages were the only good way of limiting scope, but that is no longer the case.

Other issues:

  • There is also no inherit version from parent so you would need to sync up manually.
  • You lose some of the IDE type checks because the eslint-meteor-import-resolver will only check that the package is valid, it will not follow down to read a file since it won’t know how to resolve it.
  • because of the above, some refactoring tools are not available to you either.
  • There’s more boilerplate code

I’ve had issues with this on Java land too. Where an application is broken down into separate projects and it ends up it a lot of plumbing code for small amounts of code like https://github.com/TelescopeJS/Telescope/tree/master/packages/nova-forms-tags. Things would’ve been easier to just lump most of it into one project.

When packaging I usually recommend it to be broken down by tiers (i.e. server-side, client-side, domain, services/messaging) in JEE you would do that because of their packaging structure (WAR, EAR, EJB, Web services) and refactor out reusable components that can be maintained outside the project as needed (i.e. someone from another project asked for it).

I tried to do it on Meteor, but when I did it it was more plumbing for little benefit. Meteor has well defined API starting points for client and server (i.e. put stuff into the client and server folder). The only annoying part about Meteor is anything outside those and imports are loaded in both so the only thing I would have in that common area is a gulpfile.js and JSON configuration files because the tools need it that way.

Anyway don’t let me detract you, you may have better experience.

1 Like
53

I’d disagree, and my career experience has mostly been in being the lead software architect / tech on multi-million line applications with teams of as many as 80 engineers and a co-lead on one with over 200.

That structure was developed largely because modules weren’t built into the language yet. I could see having it discussed as an alternative, but I’d rather see a much better article focused on getting the most out of modules for the mainstream large application.

In the Guide’s 1.3 Migration article the Recommendations: Modules section has a specific recommendation to convert local packages that were not created for the purpose of sharing code between applications from packages to modules within your app. In other words, the best reasons the local package organization arose have gone away. So local packages should go away in favor of the standard direction ECMAScript has chosen.

I believe that ES6 modules actually now offer a richer organization capability for large projects versus a single, usually big and flat, packages or node_modules directory. Building a full tree of all of my module’s dependencies on each other when they are in packages involves parsing every package.js and packages.json. With modules and a little organization, much of that tree can just appear in the directory structure. The interfaces are also better defined and more flexible in modules.

The only weakness I’ve seen in the module approach is that it is a bit weak on privacy. But, at least you can easily see every file’s dependencies. It would be trivial to write your own scanning mechanism to enforce whatever rules you choose about importing across certain directory boundaries. If I were writing a large product using multiple developers in Meteor today, I’d consider something like requiring an explicit comment to an export, something like // public export, that is allowed to be imported by modules that are not within or under the current directory and then creating a little script that can scan for imports that violate that between running lint and running tests.

But that even illustrates my point about the flexibility of the module system for large projects. It defines my interfaces very nicely, gets rid of global hell, and enables me to easily make rules that fit my project in a manner that follows a standard that goes well beyond Meteor – ECMAScipt.

1 Like
54

Putting all of my imports/ui/ code into imports/ui/client has dramatically reduced my build times when working on my React components. Only a client refresh is done. Is there any reason not to do this? If not, perhaps it should be the recommended structure in the Meteor Guide.

55

I’m surprised. Is there a reported issue on this? Changes in any file within an “imports” directory that is not explicitly imported into server code should not trigger a server rebuild as there are no server dependencies on the file.

56

I’m starting a new project and finally decided to ditch Blaze/Coffeescript to try React and see how much better it is.

I noticed how long it took to get UI changes reflected (5 seconds or so) and noticed the server was rebuilding every time. I moved imports/ui to imports/client/ui, kinda the opposed of @jpillar but it really helped with build times! Now client changes just refresh the browser in a second or two.

If this isn’t considered a bug then the guide should really suggest a structure with a client folder under imports. Note that having imports under client does not change anything, the server will still rebuild for client changes.

2 Likes