Basic things for the es2015 import/export


#1

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


#2

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.

I guess that’s why.

As far as the names go, I’m sure there’s some convention out there that people follow while naming stuff. https://github.com/airbnb/javascript is a very popular option. See https://github.com/airbnb/javascript#naming-conventions


#3
  1. Does it mean to avoid adding modules in .meteor/packages and using the import code instead?

… if I understand this correctly: https://guide.meteor.com/structure.html#importing-meteor-globals

  1. But even if there is a popular convention for naming, I don’t know the naming always. On atmosphere I just get the add anymodule thing…

As an example from the docs:

import { Meteor } from 'meteor/meteor';
import { EJSON } from 'meteor/ejson';

So from where can I know to use EJSON instead of ejson?


#4

The Meteor docs now show all import statements: http://docs.meteor.com/api/ejson.html

To answer your other Q’s:

Pretty much always (well, you don’t have to, but you probably should). If you use something in your code, e.g.:

axios.get('/user?ID=12345')
  .then(function (response) {
    console.log(response);
  })
  .catch(function (error) {
    console.log(error);
  });

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!).


#5

The reason they still work without it is because of backwards compatibility.

The symbols you can import from Meteor packages are declared in their package.js file:

api.export('EJSON');

How do you know the name to import?
#6

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…


#7

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.