Meteor 1.3 === import statements everywhere?

react
21

Having read all the great comments, I agree that DRY probably doesn’t apply here, and that having an explicit import is better than a magic global.

Thanks for all the feedback!

22

Having now moved my current project fully over to 1.3 (using the file structure mentioned in the 1.3 Guide - everything in /imports) I’ve found it much easier to reason with the project.

I can more easily see and understand why something is working, but more importantly why it isn’t. Yes the imports at the top are a bit of overhead, and it doesn’t feel particularly efficient when going through the refactor; but once it’s done and you are only adding new files/features/imports occasionally, the benefits outweigh the upfront work.

I can also recommend adding ESLint to Atom (if that’s what you use). It has improved the quality of my work, but also the velocity, as it flags up undefined's before they cause an issue, and helps me quickly get my codebase into a consistent, easy to consume form.

DRY is a nice to have, a solid understanding of where everything is coming from is far more valuable.

1 Like
23

True if you don’t use propTypes. I wouldn’t do that though.

24

I think the way Mantra does this is to include an index.js that imports all the stuff you need from that folder (and sub-folders), then exports it as default. So, if you want to import everything you simply import the folder, which defaults to the index.js, which in turn exports everything. I am es6 noob, though, so please don’t take this as gospel.

25

That’s not true, you can declare propTypes on stateless components.
From react 0.14 release notes

Functional components do not have lifecycle methods, but you can set .propTypes and .defaultProps as properties on the function.

26

Firstly, I completely agree with DRY being a set of guidelines. Although, in this instance, I think it’s incredibly helpful to be explicit when importing other code. I want to know what I am importing, where I am importing it, and why I am requiring it. I understand you are referring to the regular use of React but I think the same still applies.

Like @sashko said, there are already heaps of IDE plugins available to support you with a majority of your imports. I personally use Atom, and packages such as autocomplete-modules, atom-import-sort, and js-autoimport have been pretty useful.

27

I don’t think you understand what I was saying. You said you don’t need to import React in stateless components. I said that’s true, but only if you aren’t using propTypes. You need React to specify PropTypes, do you not?

const comp = () => {};

comp.propTypes =  {
    foo: React.PropTypes.string  // < ---- React is not defined, if you don't import it.
};
1 Like
28

You don’t need all of react if you aren’t using JSX, you could just import PropTypes

// If you use jsx and proptypes
import React, {PropTypes} from 'react'
// If you don't use jsx
import {PropTypes} from 'react'
1 Like
29

True, but that doesn’t get rid of the import statement.

30

You’re correct, you would use an import statement for all components.

The only time I haven’t used one is when I’m injecting React into a environment with existing libraries (jQuery) and I make $ a global within Webpack.

31

One way to go at this problem is also by having pure functions:


export default function (React, myCollection) {
  // return react component as a function
  return () => {
    return (<div>...</div>);
  };
}

Or have as @tmeasday mentioned common imports or even better a simple service that abstracts some re-occuring view logic.

1 Like
32

I think it’s a pity there is no directory import statement, in the official ES2015 spec or in Meteor otherwise. In my current project I have a lot of migrations, each in a separate file of course. An index file in the directory just imports these files: a dummy file with 20+ lines of import statements. That’s a lot of silly overhead for just including a directory of migration files. In my Rails projects, one can easily require a javascript directory in the asset pipeline.

There are NPM packages that fix these things, but these are not compatible with Meteor: “import-dir”, “import-all” and “import-all-dir”. To circumvent this, I created a shell script to index my imports directory. It writes an index file in each, which imports the files and directories under it. This way I can import directories but still customise load order. This is a solution, but I still think it’s still a problem since one has to write a tool to fix it.

1 Like