web-dev-qa-db-fra.com

Modules ES6: exportation d'une seule classe de méthodes statiques OR plusieurs méthodes individuelles

J'utilise des modules ECMAScript6. Quelle est la bonne façon d'exporter/importer plusieurs méthodes à partir d'un module à partir des options ci-dessous?

Classe unique de méthodes statiques:

//------ myClass.js ------

export default class myClass {

  static myMethod1() {
    console.log('foo'); 
  }

  static myMethod2(args...) {
    console.log('bar'); 
  }  

}

//------ app.js ------

import myClass from 'myClass';
myClass.myMethod1();    //foo

Plusieurs méthodes exportées:

//------ myMethods.js ------

export function myMethod1() {
    console.log('foo');
}

export function myMethod2() {
    console.log('bar');
}

//------ app.js ------
import {myMethod1, myMethod2} from 'myMethods';
myMethod1()    //foo;


//OR
import * as myMethods from 'myMethods';
myMethods.myMethod1()    //foo;

1) Exportation: Une classe de méthodes juste statiques ressemble à une sorte d'odeur de code, mais de la même façon, tout exporter individuellement semble un peu bavard. Est-ce simplement la préférence du développeur ou y a-t-il des implications en termes de performances?

2) Importation: la syntaxe '* as' est ma méthode préférée car elle vous permet d'utiliser la notation par points (référençant à la fois le module ET la méthode) pour faciliter la lisibilité du code. Est-ce que cela a des implications sur les performances, alors que je n'utilise que l'une des méthodes?

javascriptclassmoduleecmascript-6
37
james

Une classe de méthodes juste statiques ressemble à une sorte d'odeur de code

Oui en effet. Vous n'avez pas besoin d'une structure class ici! Exportez simplement un objet "module" normal:

//------ myMethods.js ------

export default {
  myMethod1() {
    console.log('foo'); 
  },
  myMethod2(args...) {
    console.log('bar'); 
  }  
};

Cependant, je recommande votre deuxième approche avec plusieurs exportations.

tout exporter individuellement semble un peu bavard

Eh bien, vous n'avez besoin d'aucune structure de wrapper, donc je dirais que c'est moins passe-partout. Il vous suffit de marquer explicitement tout ce que vous souhaitez exporter, ce qui n'est pas une mauvaise chose.

* as la syntaxe est ma méthode préférée car elle vous permet d'utiliser la notation par points (référençant à la fois le module ET la méthode) facilitant la lisibilité du code.

C'est une préférence très personnelle et dépend du type de code que vous écrivez. Parfois, la concision est supérieure, mais la capacité de référencer explicitement le module peut également être utile. Notez que l'espace de noms importe à l'aide de * as et les objets importés par défaut sont très similaires ici, bien que seules les exportations nommées vous permettent de les référencer directement via import {myMethod1, myMethod2}. Il vaut donc mieux laisser le choix à ceux qui importent votre module.

Cela a-t-il des implications sur les performances?

Pas tant. De toute façon, les implémentations ES6 actuelles ne visent pas à optimiser les performances.

En général, les identificateurs statiques sont plus faciles à résoudre et à optimiser que les accès aux propriétés[1], plusieurs exportations nommées et importations partielles pourraient théoriquement rendre JIT plus rapide, et bien sûr les fichiers plus petits nécessitent moins de temps à charger si les exportations inutilisées sont supprimées pendant le regroupement. Voir ici pour plus de détails. Il n'y aura guère de différences de performances notables, vous devez utiliser ce qui est mieux maintenable.

[1]: espaces de noms des modules (import * as ns) sont également statiques, même si ns.… ressemble à un accès à une propriété dynamique

41
Bergi