ES6-Module: Einzelne Klassen von statischen Methoden ODER mehrere individuelle Methoden exportieren

Question

Ich verwende ECMAScript6-Module. Was ist der richtige Weg, um mehrere Methoden eines Moduls aus den folgenden Optionen zu exportieren/importieren?

Einzel Klasse von statischen Methoden:

//------ 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 

Mehrere exportierte Methoden:

//------ 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) Exportieren: Eine Klasse nur statische Methoden fühlt sich wie ein bisschen ein ‚Codegeruch‘, sondern Ähnlich geht es, wenn man alles einzeln exportiert. Handelt es sich nur um eine Vorliebe für Entwickler oder gibt es hier Auswirkungen auf die Leistung?

2) Importieren: '* as' Syntax ist meine bevorzugte Methode, da Sie die Punktnotation (Referenzierung sowohl das Modul UND die Methode) Hilfe Code Lesbarkeit. Hat dies Auswirkungen auf die Leistung, wenn ich nur eine der Methoden verwende?

Answer 1

Eine Klasse nur statische Methoden fühlt sich wie ein bisschen ein ‚Codegeruch‘

Jawohl. Sie brauchen hier keine class Struktur! Exportieren Sie einfach ein normales "Modul" -Objekt:

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

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

Ich empfehle Ihre zweite Ansatz mit mehreren Exporten, obwohl.

Export alles einzeln fühlt sich ein bisschen ausführlicher

Nun, Sie brauchen keine Struktur Wrapper, also würde ich sagen, es ist weniger vorformulierten. Sie müssen nur alles, was Sie exportieren möchten, explizit markieren, was keine schlechte Sache ist.

* as Syntax ist meine bevorzugte Methode, da es Sie die Punktnotation verwenden können (sowohl das Modul und das Verfahren Referenzierung) die Lesbarkeit des Codes unterstützen.

Das ist sehr persönliche Präferenz und hängt von der Art des Codes ab, den Sie schreiben. Manchmal ist Prägnanz zwar besser, aber auch die Möglichkeit, explizit auf das Modul zu verweisen, kann hilfreich sein. Beachten Sie, dass benannte Exporte unter Verwendung von * as und Standardexportobjekten hier sehr ähnlich sind, obwohl nur benannte Exporte es ermöglichen, sie direkt über import {myMethod1, myMethod2} zu referenzieren.

Hat dies irgendwelche Auswirkungen auf die Leistung?

Ich glaube nicht. Aktuelle ES6-Implementierungen zielen ohnehin noch nicht auf Leistungsoptimierungen ab.

Im Allgemeinen sind statische Bezeichner leichter zu lösen und zu optimieren als Eigenschaftenzugriffe ^[1], mehrere benannte Exporte und partielle Importe könnten JIT theoretisch schneller machen, und kleinere Dateien benötigen natürlich weniger Zeit zum Laden. Details siehe here. Es wird kaum spürbare Leistungsunterschiede geben, Sie sollten verwenden, was besser wartbar ist.

_{[1]: Modul Namensraum (import * as ns) als auch statisch sind, auch wenn ns.… wie eine dynamische Eigenschaft Zugang sieht}