Почему бы вам не использовать import all в ES6

Итак, я недавно начал учиться реагировать и заметил, что во всей документации есть импорты, которые выглядят иначе:

import { Apples, Bananas, Oranges } from 'fruits';

Но при изучении реакции я обнаружил, что этот синтаксис работает так же хорошо:

import * as Fruits from 'fruits';

Мой вопрос: есть ли потеря производительности или логический конфликт с использованием синтаксиса импорта всего?

Если нет, то я просто буду использовать этот синтаксис. Я бы предпочел быть немного более подробным и не беспокоиться о том, чтобы убедиться, что все было импортировано.


reactjs javascript es6-modules ecmascript-6
person Nicholas Summers    schedule 14.11.2017    source источник
comment
Если вы используете упаковщик, который поддерживает встряхивание дерева, то первый приведет к потенциально меньшим файлам результатов.   -  person zerkms    schedule 14.11.2017
comment
и не нужно беспокоиться --- вам не нужно беспокоиться, вместо этого ваша IDE должна беспокоиться за вас.   -  person zerkms    schedule 14.11.2017
comment
@zerkms Это имеет смысл. Я использую Webpack, и я совершенно уверен, что это так.   -  person Nicholas Summers    schedule 14.11.2017
comment
В дополнение к данным ответам более конкретный импорт делает ваш код более самодокументируемым. Это, очевидно, не улучшит производительность вашего приложения, но может помочь вашему мозгу работать, когда вы оглянетесь на свой код через 6 месяцев и не будете уверены, произошло ли bananas от fruits или от yellowThings. .   -  person skylize    schedule 15.11.2017

Ответы (3)


arrow_upward
1
arrow_downward

На самом деле - это зависит от количества экспорта из данного модуля.

Если вы импортируете, например. Lodash вы можете не захотеть импортировать всю библиотеку, вам следует импортировать только те методы, которые вы собираетесь использовать в своем приложении:

import { isEmpty, pickBy, orderBy } from 'lodash';

чтобы избежать потери производительности и потери памяти.

Однако, если в вашем модуле содержится всего несколько методов или вы собираетесь использовать каждый отдельный экспорт, вы можете свободно использовать этот ярлык:

import * as Fruits from 'fruits';

Примечание. Я предполагаю, что вы используете webpack 2, который на самом деле включает алгоритм three-shaking, делающий возможным минимизацию пакета.

person kind user    schedule 14.11.2017
comment
чтобы избежать потери производительности и потери памяти. --- это должно сопровождаться некоторыми доказательствами. Или, по крайней мере, что-то, что делает это точкой. - person zerkms; 14.11.2017
comment
@zerkms Недавно тестировал это в своем приложении, весь lodash весит около 70 КБ, а импортированных методов всего несколько - 3-10 КБ в зависимости от их сложности. - person kind user; 14.11.2017
comment
Тогда вам следует упомянуть tree-shaking или альтернативную технологию. Квалифицированный импорт сам по себе ничего не улучшает. - person zerkms; 15.11.2017
comment
@zerkms Есть ли в этом мире кто-то, кто не использует React с Webpack? - person kind user; 15.11.2017
comment
Конечно: люди, которые не используют реагирующую клиентскую часть и только для SSR (статические веб-сайты) - person zerkms; 15.11.2017
comment
@zerkms Но есть тег reactjs, поэтому я полагаю, что спрашивающий на самом деле использует реакцию с Babel. - person kind user; 15.11.2017
comment
Я понимаю это: вы вполне можете использовать reactjs без webpack. И этот чат занимает слишком много времени, я выхожу :-) - person zerkms; 15.11.2017
comment
По сравнению с двумя другими, это лучший совет. В моем случае у меня есть несколько используемых библиотек, некоторые из которых я использую только частично, а некоторые, я знаю, будут использовать все или, по крайней мере, почти все компоненты. - person Nicholas Summers; 15.11.2017

arrow_upward
3
arrow_downward

Лучше использовать первый способ. Хотя бы одно: Always write explicitly what you want to use. Это лучшая практика для всех фреймворков/языков.

Если у вас есть встряска дерева, какой-то неиспользуемый модуль не будет загружен, и все должно быть хорошо (как сказал @zerkms). Но это в лучшем случае, даже самое лучшее встряхивание деревьев не идеально, и у вас может быть импорт, который все еще импортируется, даже если вы их не используете. Если ваш проект «маленький», все должно быть в порядке. Если в вашем проекте вы загружаете сотни вещей, это может быть немного по-другому.

И когда вы будете строить свой проект, вы также потеряете время на анализ дерева.

Так что только потому, что вы не хотите «терять время, написав два слова», вы потеряете время на каждой сборке и, возможно, повлияете на производительность.

person sheplu    schedule 14.11.2017

arrow_upward
1
arrow_downward

Это зависит от того, какой сборщик модулей вы используете. Если вы используете > webpack 2.0 в качестве упаковщика, это повлияет на размер пакета, потому что:

import { Apples, Bananas, Oranges } from 'fruits';

выведет только Apples, Bananas и Oranges из файла, так как webpack 2.0 использует алгоритм tree-shaking для оптимизации. Кроме того, в этом случае вам нужно позаботиться о том, чтобы вы не делали никаких default export в своем файле, вместо этого вы экспортировали const, потому что именованного экспорта было бы достаточно.

import * as Fruits from 'fruits';

просто принес бы все, что заявлено в файле fruits.

Я нашел этот замечательный разговор с Дэном Абрамовым в твиттере, и он должен вам помочь.

https://twitter.com/dan_abramov/status/927835086577430529

ИЗМЕНИТЬ

В случае lodash вы, вероятно, захотите использовать babel-lodash-plugin. Если бы вы использовали это, вам не пришлось бы делать

import {isEmpty, isUndefined} from 'lodash';

и ты можешь сделать

import _ from 'lodash';

так как он не приносит вам всю библиотеку.

person Ajay Gaur    schedule 14.11.2017