Если вы похожи на меня, вас иногда (или часто) смущает оператор импорта в JavaScript. Это относительно новое (в компьютерные годы оно старше меня) утверждение, которое было добавлено в JavaScript для стандартизации и официальной поддержки импорта элементов из других файлов.

Но все же сегодня я иногда смотрю на синтаксис оператора импорта и дважды обращаюсь к нему. Когда я начинаю привыкать к фигурным скобкам, внезапно появляется звездочка или вообще ничего. Почему происходит так много вариаций? И да, деструктуризация - отличная вещь, но ее синтаксис с фигурными скобками иногда вызывает у меня головную боль.

Итак, давайте разберем оператор импорта и рассмотрим все возможные варианты и то, что они делают.

Первое, что нужно понять, это то, что цель оператора импорта - перенести что-то из одного файла JavaScript в другой. Это может быть функция, класс, объект или что-то еще в JavaScript (кроме, возможно, самореализации. Вам придется искать это в другом месте).

Глядя на следующую техническую диаграмму, которую я создавал часами, мы можем увидеть взаимосвязь между двумя файлами и то, как оператор импорта помогает одному файлу импортировать объекты из другого файла.

Давайте посмотрим на синтаксис этого

Это может показаться довольно простым, но это не так. Возможно, это вас уже сбивает с толку. Проблема в том, что когда вы узнаете это, просто глядя на то, что делают другие люди, вы можете предположить, что что-то не так. Здесь мы импортируем утилиту из утилит. Таким образом, вы МОЖЕТЕ подумать, что это означает, что файл утилит содержит нечто, называемое утилитой, и что мы просим об этом. И вы также можете, естественно, предположить, что полезность имени важна. Ни одно из утверждений не соответствует действительности. Утилита идентификатора создается прямо в операторе импорта. И это может быть любое имя. Например, следующий текст также действителен без изменений в файле утилит.

Здесь я назвал это обезьянами вместо полезности. Это так же верно. Этот код будет делать то же самое, что и предыдущий. Я определился с именем, когда писал заявление об импорте. Я назвал его обезьянами. Нет никакой корреляции между этим именем и тем, что находится в файле утилит.

Есть корреляция между тем, КАК я импортирую, или синтаксисом, который я здесь использую, и тем, что находится в файле утилит. В данном случае это синтаксис импорта, когда файл утилит имеет экспорт по умолчанию. Давайте взглянем на файл утилит и посмотрим, что в нем содержится.

Во-первых, мы видим, что имена в нашем файле утилит не соответствуют именам в нашем файле кода, в который мы импортируем. Сначала мы взяли эту функцию собак и импортировали ее под именем утилита. Затем мы импортировали его под названием обезьяны.

Как правило, вам нужна корреляция. Обычно любые имена в исходном файле полезны, потому что они описательны. Переименование функции собаки в обезьяны, вероятно, не является хорошей практикой для удобочитаемости.

Теперь давайте посмотрим на это утверждение по умолчанию. Оператор экспорта позволяет нам что-то экспортировать, ключевое слово по умолчанию указывает, что это экспорт по умолчанию. "Там может быть только один". Итак, если это то, что находится в файле утилит, то синтаксис, который мы видели ранее, заключается в том, как мы импортируем это.

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

Давайте посмотрим на следующий вариант импорта, наиболее часто используемый.

Здесь я экспортирую две разные вещи из файла утилит. Функция коровы и функция кошки. Итак, есть две возможные запутанные части этого импорта. Во-первых, синтаксис. Это синтаксис деструктурирования объекта в JavaScript. Мы не будем вдаваться в подробности здесь, просто скажем, что это круто, и если вы не очень к этому привыкли, это легко запутать.

Другая, возможно, сбивающая с толку вещь, заключается в том, что теперь имена, которые мы используем, ДОЛЖНЫ коррелировать с тем, что находится в нашем файле импорта. Используя этот синтаксис, имена должны совпадать. Я не могу импортировать функцию обезьян как кошек вроде этой (есть способ сделать это, мы увидим позже). Я должен использовать то же имя. Точно такое же имя. Давайте посмотрим, что в нашем файле утилит заставляет это работать.

Здесь мы экспортируем две функции: одну с именем cows, а другую с кошками. Имена должны совпадать. Так что вас не смущает тот факт, что при импорте первым способом, используя экспорт по умолчанию, имя не должно совпадать, а при другом способе, используя синтаксис деструктуризации объекта, имена должны совпадать. Держи это прямо.

Теперь давайте посмотрим, как переименовывать эти идентификаторы при их импорте:

Мы можем просто использовать ключевое слово as, а затем выбрать собственное имя. В большинстве случаев люди этого не делают. Но это возможно.

Теперь давайте посмотрим на следующий вариант импорта, который снова легко сбивает с толку.

Здесь мы группируем все, что экспортируется, в один объект. Затем мы можем использовать этот объект для доступа ко всему, что было экспортировано. Нам действительно нужно знать имена экспортированных вещей, чтобы мы могли их называть. И мы не можем переименовывать части, но нам это и не нужно, поскольку все они собраны вместе. Имя, которое я придумал, животные, может быть чем угодно. Это создается только здесь, в операторе импорта. Он не связан ни с одним именем в файле, из которого мы импортируем. Это просто создает объект (в нашем случае с именем animals), который содержит все экспортные данные из файла, который мы импортируем.

Одно примечание: если есть экспорт по умолчанию, он отображается как член этого объекта с именем default.

Последний синтаксис, на который я хочу взглянуть, снова смутил меня, когда я впервые его увидел.

Я, наконец, начал привыкать к импорту с использованием синтаксиса деструктурирования объектов, а потом я увидел это и подумал ... Я просто не могу даже. Интересно, что здесь происходит? В чем суть? Что происходит с этим файлом?

Что ж, ответ в том, что мы используем этот синтаксис, когда хотим импортировать файл только для побочных эффектов. Например, файлы css или файлы javascript, которые создают глобальные объекты (это более старая привычка, но все еще используется сегодня) и т. Д. Итак, если вы видите это, значит, вы знаете, что что-то происходит, но вы не всегда можете быть уверены на 100% в том, что .

Вот и все. Это заявление об импорте. Здесь есть несколько вариаций, но это основные варианты использования, с которыми вы столкнетесь. Надеюсь, это поможет.

Удачного кодирования!

Подпишитесь на мою рассылку здесь.

Приходите к нам: thinkster.io | Facebook: @gothinkster | Twitter: @GoThinkster