I’m using the ES2015 import and export syntax for my meteor app.
In the docs code is shown like this:
import { Meteor } from 'meteor/meteor';
import { HTTP } from 'meteor/http';
import { FlowRouter } from 'meteor/kadira:flow-router';
import { BlazeLayout } from 'meteor/kadira:blaze-layout';
import { AccountsTemplates } from 'meteor/useraccounts:core';
I don’t really understand when I have to use these imports. As I added those modules to my app (.meteor/packages), I can leave these lines and the app is still working. So I need a little more explanation for that.
And on the other hand: From where do I get the info for the parameter used for that import code? I mean if I’m importing any module, I don’t know which term I have to use for the import. First I thought it is just the module name written in camleCase - kadira:blaze-layout gets BlazeLayout- but that wouldn’t work for useraccounts:core
Well, I don’t know if this ‘answer’ will really answer you question.
I think things are moving in the javascript world in a general direction where, among other ideas, the idea of atomicity, and of modularity is being promoted and increasingly adopted.
Modularity is taken for granted as something which has value in software engineering, perhaps without always a well articulated understanding of what it is, and why it is valuable.
“Programs that have many direct interrelationships between any two random parts of the program code are less modular (more tightly coupled) than programs where those relationships occur mainly at well-defined interfaces between modules. Modules provide a separation between interface and implementation. A module interface expresses the elements that are provided and required by the module. The elements defined in the interface are visible to other modules. The implementation contains the working code that corresponds to the elements declared in the interface.” - Wikipedia on Modularity.
What we should be aiming for is, as near as it gets, to standalone subroutines. Routines that has few outputs affecting the other subroutines. Not one where Section A is tangled up with 5 connections to Section C and 23 connections to Section B, because plucking out Section A is going to break B and C, which may break B and C’s own extended dependencies.
Then it’s extremely likely you’ll have to import it.
import axios from 'axios';
It’s a good habit to get into, because the rest of the modern JS world works this way. Meteor has shielded people from it up until recently. Yes, in Meteor you don’t have to import them, but that could change in the future (IMO it should change), so again, it’s a good habit to develop! Plus it’ll make it easier for you to pinpoint issues in your code because you’ll know exactly where certain packages are being used.
The documentation for any given package will tell you. Look on GitHub at projects like axios, radium, react-motion, formous (shameless plug!).
Is it possible to ‘deactivate’ the meteor ‘shield’? Because it doesn’t have any effect, if I add the import statements, I don’t get it, if I’m missing a single statement or put it on the wrong place…
No, unfortunately Meteor still implicitly loads things even if they’re not imported. The way to work around this currently is to put all your code into an imports folder at the root level, and then use client and server folders to just import what you want inside /imports. Then you have full control over what’s loaded.