Analysis of ES6 module usage issues

After ES6 introduced the concept of modularity, JavaScript became a new-age wanderer.

During the use, I found some problems or things I didn't understand. I will make a summary here.

It does not involve commonjs, only for importandexport

---

Take React as an example

Export a function component, conventional writing:

export default function App() {
    
    
  return (
    <div>
      <h1>APP</h1>
    </div>
  )
}

Here I can choose to erase the function name, no problem.

export default function () {
    
    
  return (
    <div>
      <h1>APP</h1>
    </div>
  )
}

Compared with the former, one difference that can be observed is that in the browser React developer tools, the component name becomes default.

Secondly, the default export is usually written at the end of the file for easy observation. This is a best practice, so it needs to be rewritten.

function App() {
    
    
  return (
    <div>
      <h1>APP</h1>
    </div>
  )
}

export default App

In the early days, my writing method was mostly like the first example, where I wrote the export and function definition on one line, for no other reason than to keep the number of lines of code small. When I read some source code later, I found that most of the default exports were written at the end, so I chose this writing method and followed the big guys.

---

Continue to explore

Only discuss the problems that arise, not the practicalities

Continuing with the above example, if you are pursuing simplification, rewrite it as an arrow function.

const App = () => (
  <div>
    <h1>APP</h1>
  </div>
)

export default App

Extreme writing method

export default () => (
  <div>
    <h1>APP</h1>
  </div>
)

But if it is written like this, it won’t work.

export default const App = () => (
  <div>
    <h1>APP</h1>
  </div>
)

In fact, if is defaultremoved, this export will work again. Coupled with the previous successful default export, this behavior makes the error even more confusing. I found this answer in the forum.

https://stackoverflow.com/questions/36261225/why-is-export-default-const-invalid

First of all, it needs to be clear that each file can only have one default export. If you want to export multiple data by default, you need to use objects.

For variable declarations, we usually write them one by one, but you can use commas to separate them and declare multiple variables at once.

const a = 1
const b = 2

const c = 3,
      d = 4

If you really declare multiple variables, the rules of default export will be broken. To prevent this from happening, export defaultit cannot exist on the same line as the variable declaration .

exportNo problem, it can accept multiple exports.

---

Let’s look at another scenario that doesn’t work

import store from "./store"

// bad
export store

import store from "./store"

export default store

Why does the former fail to take effect? ​​To be fair, it is imported from another file. Isn't it just right to export it by name?

Changing the scene can better reflect this.

const store = 10  

// bad
export store

It's fine if it's an object, but what if it's a simple type? There is no way to receive it on the other side.

export 10

For simple types, they can only be exported in object or default form

const store = 10  

export {
    
    
  store
}

For data imported by default, it can only be exported by default again, otherwise it can be added {}. This can add a corresponding key value.

---

When I was browsing some libraries, I found a way of writing like this

export {
    
     default as store } from "./store"

This is a combination writing method. When importing the target file and exporting it by default, give it a name and export it in the current file, which is the transfer station gameplay without any secondary processing.

import store from "./store"
export {
    
     store }

---

I found that there were still some unfinished questions, so I published this sequel.