查看原文
其他

【英】JavaScript Module Cheatsheet

samanthaming 前端早读课 2019-12-16

前言

本期英文文章来自@samanthaming分享。

英文从这开始~~

Here's a cheat sheet to show you the different ways of exporting and the corresponding way to import it. It really distills to 3 types: name, default, and list. Just make sure your export matches your import way and you will have no problem 👍

  1. // Name Export | Name Import

  2. export const name = 'value'

  3. import { name } from '...'


  4. // Default Export | Default Import

  5. export default 'value'

  6. import anyName from '...'


  7. // Rename Export | NameImport

  8. export { name as newName }

  9. import { newName } from '...'


  10. // Name + Default | Import All

  11. export const name = 'value'

  12. export default 'value'

  13. import * as anyName from '...'


  14. // Export List + Rename | Import List + Rename

  15. export {

  16. name1,

  17. name2 as newName2

  18. }

  19. import {

  20. name1 as newName1,

  21. newName2

  22. } from '...'

Now let's look at each of them and see how they work 🤓

a. Name

The key here is having a name. Hence a "named" export lol 😂

  1. export const name = 'value';

  1. import { name } from '...';


  2. console.log(name); // 'value'

❌ What did I say, no name, no export!

  1. export 'value'


  2. import { } // 👈 see I don't even know what to put here...give me a name!

b. Default

With a default export, you don't need any name. Because you can name it whatever you want 👏

  1. export default 'value'

  1. import anyName from '...';


  2. console.log(anyName); // 'value'

❌ No Variable Declaration with Default

  1. export default const name = 'value'; // don't try to give me a name!

Mixing Default + Name

You can absolutely combine default and name export in one file 🤝

  1. export const name = 'value';

  2. export default 'value'

  1. import anyName, { name } from '...';

c. Export List

The third style is Export List.

  1. const name1 = 'value1';

  2. const name2 = 'value2';


  3. export {

  4. name1,

  5. name2

  6. }

  1. import {

  2. name1,

  3. name2

  4. } from '...'


  5. console.log(

  6. name1, // 'value1'

  7. name2, // 'value2'

  8. )

One important thing to note is that these lists are NOT objects. Yes, I know it looks like it. But it isn't. I made this confusion when I first learned modules. It's not an object, it's an export list!

  1. // ❌ Export list ≠ Object

  2. export {

  3. name: 'name'

  4. }

Renaming Export

Not happy with the export name. No problem, you can rename it using the as keyword.

  1. const name = 'value'


  2. export {

  3. name as newName

  4. }

  1. import { newName } from '...'


  2. console.log(newName); // 'value'


  3. // Original name is not accessible

  4. console.log(name); // ❌ undefined

❌ Can not combine inline export with export list

  1. export const name = 'value';


  2. // You're already exporting name ☝️, don't export me again

  3. export {

  4. name

  5. }

Renaming Import

The same rule applies to import. We can rename it using the as keyword.

  1. const name1 = 'value1';

  2. const name2 = 'value2';


  3. export {

  4. name1,

  5. name2 as newName2

  6. }

  1. import {

  2. name1 as newName1,

  3. newName2

  4. } from '...'


  5. console.log(newName1); // 'value1'

  6. console.log(newName2); // 'value2'


  7. name1; // undefined

  8. name2; // undefined

Import All
  1. export const name = 'value';


  2. export default 'defaultValue';

  1. import * as anyName from '...';


  2. console.log(anyName.name); // 'value'

  3. console.log(anyName.default); // 'defaultValue'

Name vs Default

There's been a lot of debate whether one should use default export at all. Check out these 2 articles.

  • Why I've stopped exporting defaults from my JavaScript modules

  • GitLab RFC by Thomas Randolph

Like with anything, there is no right or wrong answer. The right way is always what's best for you and your team. But here's how I can think of this debate. Samantha's Story Time ...

Name vs Default Export in Non-Dev Terms

Let's say you owe your friend some money. Your friend says you can pay them back with cash or e-transfer. Paying through e-transfer is like a named export because your name is attached to the transaction. So if your friend is forgetful and starts chasing you down claiming that you still owe them money. You can simply show them the proof of transfer because your name is on the payment. However, if you had paid your friend back with cash, which is like a default export, you have no proof. They can say the $50 is from Susan and NOT you. The cash has no name attached to it so they could say it's from you or whoever it is 😵

So is it better to go with e-transfer (named export) or cash (default export)? Well that depends, do you trust your friend or not 🤔 Actually, that's not the right way to frame this dilemma. A better solution is to NOT put your relationship in that position. It's better to be explicit so you don't risk jeopardizing your friendship. And yes, this idea also applies to whether you pick named or default export. I prefer to be more explicit, so your code is crystal clear. But of course, your code is your code. And you can do whatever works for you and your team 😄

Community Input

@kyleshevlin: Maybe there's a way you could add the asterisk import, too, where you import all exports from a module. import * as myModule from '/modules/my-module.js';. The key with that one is that on the import side when using the module, the default is there as myModule.default and the rest are as they are named, myModule.nameOfSomething. CodeSandbox Example

@erikayabar: 👍 the emphasis on anyName here for default exports! *This is why I prefer named exports, but it seems community is set on default export all the things (especially React components) so it's good to understand the difference! Also seen confused: named imports != destructuring

关于本文 作者:@samanthaming 原文:https://dev.to/samanthaming/javascript-module-cheatsheet-5b4o

为你推荐


【英】在JavaScript中使用查询参数

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存