it-swarm.com.de

Platzhalter oder Sternchen (*) vs. benanntes oder selektives Importieren von JavaScript

Ich frage mich nur, welche der beste Weg ist, um import zu benutzen:

import * as Foo from './foo';

VS:

import { bar, bar2, bar3 } from './foo';

Ich verwende beispielsweise Webpack für die Bündelung aller JavaScript-Dateien. Wird der erste tatsächlich alles importieren, obwohl ich sie nicht im Hauptcode verwende?

Einige Referenzen, die ich finden kann, sind:

In Airbnb-Styleguide wird kein Platzhalter empfohlen, sodass es immer ein Standardimportobjekt und dies gibt.

17
andiwin

Wenn Sie Webpack mit der durch das neue uglify bereitgestellten Dead Code Elimination oder Rollupjs mit Tree-Shaking verwenden, werden die nicht verwendeten Importe entfernt.

Ich stimme dem airbnb styleguide teilweise zu, keine Wildcard-Importe zu verwenden, obwohl die Wildcard-Importe von Javascripts nicht an den gleichen Krankheiten leiden wie beispielsweise Pythons oder Javas-Wildcard-Importe kann nur über moduleB.foo auf sie zugreifen, nicht foo bei Verwendung von import * as moduleB from ...).

Zum Testartikel: Ich verstehe die Bedenken irgendwie, sehe aber nichts, was dort nicht gelöst werden kann. Sie können die Importe selbst mit einem benutzerdefinierten Modul-Loader simulieren (ein benutzerdefiniertes AMD-Modul-Loader ist buchstäblich 15 Zeilen Code), so dass Sie sich nicht mit dem lokalen Bereich des getesteten Moduls herumschlagen müssen.

14
Tamas Hegedus

Zu diesem Teil der Frage: 

Wird der erste tatsächlich alles importieren, obwohl ich sie nicht im Hauptcode verwende?

So wird es mit Babel 6.26 kompiliert:

Genannt

import { bar, bar2, bar3 } from './foo';

... wird ...

'use strict';

var _foo = require('./foo');

Wildcard

import * as Foo from './foo';

... wird ...

'use strict';

var _foo = require('./foo');

var Foo = _interopRequireWildcard(_foo);

function _interopRequireWildcard(obj) { 
    if (obj && obj.__esModule) { 
        return obj;
    } else {
        var newObj = {}; 
        if (obj != null) { 
            for (var key in obj) { 
                if (Object.prototype.hasOwnProperty.call(obj, key))
                    newObj[key] = obj[key];
            }
        }
        newObj.default = obj; 
        return newObj;
    }
}

In beiden Fällen wird die gesamte Datei über require importiert. 

Beim Import von Platzhaltern wird eine _interopRequireWildcard-Funktion definiert, mit der alle Exporte der Namespace-Variablen zugewiesen werden.

Es ist erwähnenswert, dass der kompilierte Code nur eine einzige _interopRequireWildcard-Definition und einen Aufruf von require und _interopRequireWildcard für jeden Import enthält.

Letztendlich erfordert die Verwendung von Platzhalterimporten zur Laufzeit etwas mehr Verarbeitungsaufwand und führt zu einer geringfügigen Vergrößerung der kompilierten Js.

10
idmadj

Ich stimme @Tamas zu.
Wenn Sie vollen Zugriff auf alle Exporte in der Zieldatei benötigen, können Sie import * as Foo from './foo'; Oder import foo from './foo': verwenden. 

wenn Sie jedoch bestimmte Funktionen oder const verwenden müssen, vermeiden Sie besser "import *" und machen Sie deutlich, was Sie tun müssen.

3
Moeen Basra

Da bei einem modernen WebPack-Setup die beiden die gleiche kompilierte/transpilierte JS generieren, ist der tatsächliche Wert der genannten Importe, wie viel ausdrucksvoller sie ist. Durch die Benennung Ihrer Importe sagen Sie jedem, der die Datei mit den Funktionen eines Moduls öffnet, das Sie verwenden möchten. Ein Beispiel dafür, wo dies hilfreich sein kann, ist das Schreiben von Tests. Wenn Verspottungen erforderlich sind, haben Sie eine explizite Liste von Importen in Verspottungen. 

0
Kelly Anderson