So I recently started learning react and noticed that all the documentation has imports that look like else:

import { Apples, Bananas, Oranges } from 'fruits';

But while studying react I found that this syntax works just as well:

import * as Fruits from 'fruits';

My Question: Is there any performance loss or logical conflict with using the import all syntax?

If there is not then I will just keep using that syntax. I would rather be a little more verbose and not have to worry about making sure everything has been imported.

So I recently started learning react and noticed that all the documentation has imports that look like else:

import { Apples, Bananas, Oranges } from 'fruits';

But while studying react I found that this syntax works just as well:

import * as Fruits from 'fruits';

My Question: Is there any performance loss or logical conflict with using the import all syntax?

If there is not then I will just keep using that syntax. I would rather be a little more verbose and not have to worry about making sure everything has been imported.

• javascript
• reactjs
• ecmascript-6
• es6-modules

• 2 If you use a bundler that supports tree-shaking then the former would lead to potentially smaller result files. – zerkms Commented Nov 14, 2017 at 20:49
• 1 "and not have to worry" --- you don't need to worry, your IDE should worry for you instead. – zerkms Commented Nov 14, 2017 at 20:50
• @zerkms That makes sense. I am using Webpack and I am fairly certain it does. – Nicholas Summers Commented Nov 14, 2017 at 20:51
• In addition to the answers given, the more specific imports make your code more self-documenting. This obviously doesn't help your app perform, but it might help your brain perform when you look back at your code 6 months from now, and you're not sure whether bananas came from fruits or from yellowThings. – skylize Commented Nov 15, 2017 at 3:35

3 Answers 3

It would be better to use the first way. At least for one thing: Always write explicitly what you want to use. It's a best practice in all framework / language.

If you have some tree-shaking, some unused module won't be loaded and everything should be good (like @zerkms said). But it's in the best world case, even the best tree shaking isn't perfect and you could have some import still being imported even if you don't use them. If your project is 'small' it should be ok. If in your project you load hundreds stuff, it could be a little bit different.

And when you will build your project, you will loose time with the tree-shaking analysis too.

So just because you don't want to "loose time by writing two words" you will loose time on every build and maybe have a performance impact

Actually - it depends on the amount of exports from given module.

If you import e.g. Lodash you might not want to import whole library, you should import only these methods which you are going to use in your application:

import { isEmpty, pickBy, orderBy } from 'lodash';

to avoid performance loss and memory waste.

However, if your given module holds just a few methods or basically you are going to use every single export, then you can freely use that shortcut:

import * as Fruits from 'fruits';

Note: I suppose you are using webpack 2, which actually includes three-shaking algorithm which makes minifying the bundle possible.

That depends upon what module bundler you're using. If you're using > webpack 2.0 as your bundler then it would affect the bundle size because :

import { Apples, Bananas, Oranges } from 'fruits';

will only bring Apples, Bananas and Oranges from the file as webpack 2.0 uses tree-shaking algorithm for optimisation. Also, in that case, you need to take care that you don't do any default export in your file, instead you export const because named exports would suffice that.

import * as Fruits from 'fruits';

would just bring everything declared in fruits file.

I found this great conversation with Dan Abramov on twitter and that should help you.

https://twitter./dan_abramov/status/927835086577430529

EDIT

In case of lodash, you'd probably want to use babel-lodash-plugin. If you'd use that then you won't have to do

import {isEmpty, isUndefined} from 'lodash';

and you can do

import _ from 'lodash';

as it doesn't bring the whole library for you.