2017-12-07 3 views
1

Ich bin nur in Verwendung es 6 Module für Frontend-Entwicklung bekommen (wir überhaupt nicht verwenden Node), und frage mich, ob dieses Muster wir gekommen sind, bis alle Tücken hat oder wenn Sie haben Verbesserungsvorschläge. Ich nehme an, dass es einige Gründe für das aufschlussreiche Modulmuster in ES6-Modulen verwendet. Ich stelle diese Frage, weil die meisten es6 Modul "wie zu führen" Ich habe gesehen, etwas anderes zu tun, was ich am Ende der Frage notieren werde.ES6 Module + Aufdecken Modul Muster

Einige Dinge zu beachten:

  • Wir (sind ziemlich sicher, dass wir) jedes Modul wollen nur eins exportieren. Dies wird als Best Practice in der Airbnb Style Guide aufgeführt sind, und wir haben festgestellt, nur es schön Gesamt beim Verzehr von NPM-Pakete
  • Wir mögen Methoden mit „öffentlich“ und „privat“ zu benennen (denke, wir verwenden sollten _ für private Methoden wie die neuere best-Practice) ist, macht es einfach, zu sehen, was außerhalb des Moduls verfügbar ist

module.js:

// publicly available method 
function publicHello() { 
    return 'Hello'; 
}; 

// publicly available method 
function publicHelloWorld(){ 
    const a = publicHello(); 
    const b = privateProcessWorld(a); 
    return b; 
}; 

// private method 
function privateProcessWorld(x) { 
    return x + ' world'; 
}; 


// create an object to export, containing only the public methods 
// note that we rename them here as well, making them easier to consume 
const exp = { 
    h: publicHello, 
    hw: publicHelloWorld, 
}; 

// export the object as default so it can be used in an unnamed import 
export default exp; 

das Modul zu verbrauchen:

import whatever from "module.js"; 

whatever.h(); // "Hello" 
whatever.hw(); // "Hello world" 

Was ich in den meisten gesehen haben „es6 Modul, wie man“ Führer ist dies:

var utils = { 
    generateRandom: function() { 
    return Math.random();  
    }, 
    sum: function(a, b) { 
    return a + b; 
    } 
}; 

export default utils; 
+0

Das zweite ist kürzer und enshures eine gute Struktur. Es gibt jedoch auch viele gute Anwendungsfälle für das erste Muster. Und statt 'public/private' ist es ein übliches Muster, um mit einem' _' oder '#' zu pivotieren, bevor –

+0

@JonasW. Könnten Sie erweitern, was Sie unter "sorgt für eine gute Struktur" verstehen? Ich vermute, meine erste Frage in dieser Hinsicht wäre, wo private Methoden/vars gehen, über oder unter var utils? Auch ja, wir sollten sagen _ ist die beste Praxis; Als wir vor langer Zeit begannen, öffentlich/privat zu nutzen, haben wir unsere Wege nie geändert. – KayakinKoder

+1

"* Wir möchten, dass jedes Modul nur eine Sache exportiert. Dies wird als Best Practice im Airbnb Style Guide aufgeführt." - Nein, Airbnb hat die Funktionsweise von Modulen missverstanden. [Bitte tun Sie das nicht] (https://stackoverflow.com/a/44373830/1048572). – Bergi

Antwort

1

Wir (sind ziemlich sicher, dass wir) jedes Modul wollen nur eins exportieren.

Nein. Tun Sie dies nicht. Wenn Ihr Modul mehrere Funktionen bietet, z. B. eine Reihe von Hilfsfunktionen, und keine einzelne Funktion oder einzelne Klasse oder etwas bereitstellt, sollten Sie auch mehrere Dinge exportieren.

einfach Ihre Standardexport ändern

export { 
    publicHello as h, 
    publicHelloWorld as hw, 
} 

und Ihre Import

import * as whatever from "module.js"; 
+0

Während meiner Recherchen lese ich die Stapelantwort, die Sie in Ihrem Kommentar verlinkt haben, und habe ein paar ähnliche Antworten wie hier gelesen, aber ich habe nie explizite Gründe gesehen * warum * wir sollten mehrere Dinge exportieren. Was ist die Argumentation, nur dass "sie verschiedene Dinge tun, so dass sie anders benannt werden sollten"? (Auch, npm Pakete von "großen Unternehmen", die wir verwenden [Filestack, Opentok ...] alle scheinen eine Sache zu exportieren, denke ich, also habe ich einfach angenommen. Ich könnte auf Filestacks API schauen und sagt, es macht "eine Sache "- lassen Sie uns ihre API verwenden - oder mehrere Dinge: hochladen, Bild bearbeiten, etc.) – KayakinKoder

+0

a) Es ist kürzer b) es ermöglicht Ihnen die Verwendung einzelner named Importe (' Import {h, hw} from 'Modul.js ";') wenn du das machen willst c) hilft es Baumschütteln (im Buildstadium) und ähnliche Optimierungen (auch in der Engine) d) das ist genau der Use Case, den named exports für – Bergi

+0

entworfen wurden Danke, viel Der einzige Vorteil, den ich wirklich von diesen drei interessieren würde, wäre c), und https://rollupjs.org/ behandelt Baumschütteln ohne namentlich genannte Importe. Also ich denke, ich bin immer noch nicht überzeugt:/Edit - vielleicht eine Das Argument wäre, dass wenn wir Module im Browser verwenden können, sie vielleicht benannte Exporte benötigen (oder schneller verarbeiten können), um das Schütteln von Bäumen zu handhaben. Und du hast d) hinzugefügt, also wenn die Spezifikation dies sagt, ist das im Allgemeinen ein guter Grund. – KayakinKoder