Analyse des problèmes d'utilisation du module ES6 (suite)

Préface

Après la publication de l'article précédent , j'ai découvert qu'il restait encore des problèmes sans réponse, j'ai donc publié cette suite.

bizarreexport

Comme mentionné précédemment, ce type de valeur de clé sans utiliser l'exportation par défaut n'est pas valide :

const text = "index.js"

// error
export text

Convertissez-le et cela devient comme ceci :

export "index.js"

Mais c'est bien de l'écrire comme ceci :

export const text = "index.js"

Dans ce cas, le nom de la variable est traité comme la clé et la conversion n'est pas aussi approfondie.

Je suis également un peu confus quant à l'ampleur de la différence entre les deux. Quoi qu'il en soit, j'ai juste pris un nom de variable et je ne l'ai pas écrit directement. N'est-il pas préférable d'utiliser le nom de la variable comme cléexport "index.js" ?

En plus, ce n'est pas vous export default, ne pouvez-vous pas exporêtre plus tolérant ? Mais le problème est plus grave qu'on ne l'imaginait.

exportExportation par lots

Regardons-en un autre, l'exportation par lots sous forme d'objet.

const text = "index.js"

export {
    
    
  text
}

Cependant, si vous y écrivez directement une valeur, cela ne fonctionnera pas.

const text = "index.js"

// error
export {
    
    
  text,
  a: 10
}

C'est une autre chose que l'exportation par défaut puisse être jouée comme ceci. Après tout, d'autres peuvent exporter directement des types simples, et il n'y a rien d'autre qu'ils ne puissent faire.

Parlons un peu des raisons pour lesquelles cette exportation sous forme de paires clé-valeur régulières n'est pas disponible.

Et les exigences sont très anormales. Seules les abréviations sont autorisées ici. En d'autres termes, quel que soit le nom de la variable, la clé l'est. Vous ne pouvez pas la renommer et l'exporter.

const text = "index.js"

// error
export {
    
    
  newText: text
}

Cela soulève le niveau de la question de plusieurs niveaux. S'il y a un problème avec l'écriture directe d'une valeur, je peux la traiter comme une constante. Vous ne pouvez pas exporter une constante. Au moins, elle doit être recouverte d'une variable, même si elle est déclarée. avec const. Alors maintenant, renommer la clé et exporter une variable existante a été opposé, il n'y a donc aucun moyen d'en parler.

Personne ne modifiera directement les valeurs importées, et ce comportement est totalement interdit.

Eh bien, j'ai essayé une tactique détournée, en préparant d'abord une variable d'objet, puis en l'exportant, mais cela a toujours échoué.

const text = "index.js"

const obj = {
    
    
  text
}
  
// error
export obj

Mais le problème est soudain devenu clair : ce n’était pas pour une certaine valeur, mais pour tout le monde. Si vous souhaitez exporter cette variable, vous devez également utiliser la déclaration de variable.

const text = "index.js"

// OK
export const obj = {
    
    
  newText: text
}

Bon gars, c'est-à-dire export defaultle contraire de , l'un ne peut pas utiliser de déclaration et l'autre doit déclarer. Cependant, il offre également export {}un moyen d’écrire des exports par lots, ce qui est beaucoup plus intéressant.

Résoudre des puzzles

J'essaie de trouver la raison pour laquelle cela ne peut pas être fait, ou une solution. J'ai relu « Introduction à ES6 » du professeur Ruan et j'ai trouvé la réponse à laquelle je pensais.

https://es6.ruanyifeng.com/#docs/module

Tout d’abord, l’action de ne peut export {}être considérée comme une « exportation d’un objet ». Il s'agit d'une interface exposée en externe et les règles sont exportactivées par . Alors, si ce qui est exporté est un objet, comment l’autre partie le reçoit-il ? En fait, tout comme l'exportation précédente de types simples, une revendication de clé est requise. Même les types de référence ne peuvent pas être utilisés de cette manière, sauf s'il s'agit de export default.

Après avoir compris le point précédent, il est facile d’envisager de renommer l’exportation. Ce n'est pas un objet, c'est juste une représentation similaire. Renommer est possible, mais cela ne peut pas être écrit ainsi. Au lieu de cela, il doit être utilisé as. Les objets normaux ne peuvent pas être utilisés as.

const text = "index.js"

// OK
export {
    
    
  text as newText
}

Enfin, veillez à ce que les actions exportées soient cohérentes. Il existe deux formulaires, il suffit d'en choisir un. Il est préférable de ne pas les mélanger.

const a = "a"
const b = "b"

export {
    
    
  a,
  b
}

export const a = "a"
export const b = "b"

Autres poses d'exportation

Il existe un moyen, adapté à l'export en station de transfert, export *d'illustrer par un exemple :

// a.js
export const a = "a"
export const b = "b"

export default {
    
    
  a,
  b
}

// b.js
export * from "./a.js"

// index.js
import * as b from "./b.js"

// { a: "a", b: "b"}
console.log(b)

Cette exportation n'est pas accompagnée d'une exportation par défaut et nécessite des ajouts supplémentaires.

// b.js
export * from "./a.js"
export {
    
     default } from "./a.js"

Cette approche entraînera b.jsla synchronisation de l'exportation par défaut a.jsavec , mais elle ne peut pas être écrite comme ceci.

// b.js
export * from "./a.js"

// bad
export default from "./a.js"

En comparaison, cette façon d’écrire est plus facile à comprendre, mais bien sûr elle n’existe pas.