импорт скрипта js в js
Разбираемся с модулями, операторами импорта и экспорта в JavaScript
Введение
В настоящее время, при разработке современных приложений на Javascript, существует необходимость в использовании стороннего кода для решения общих задач, разделения кода на файлы отдельных модулей, а также внедрения комплекса мер для защиты от засорения глобального пространства имен.
Модульное программирование
В файл index.html будет отображаться сумма, разность, произведение и частное двух чисел, в него же в тегах script поместим ссылку на два JavaScript файла.
И так создайте файл index.html в текстовом редакторе и добавьте в него следующий код:
Откройте файл functions.js и добавьте в него следующий код:
После подключения к index.html Javascript файлов, можете открыть его в браузере, где увидите следующий результат.
Для веб-сайтов в которых используются несколько небольших скриптов это достаточно эффективный способ: просто разделить код по разным скриптам (файлам). Однако с этим подходом связаны некоторые проблемы, в том числе:
Теперь вы сможете перезагрузить обновленную страницу, и ваш веб-сайт будет использовать нативный механизм модулей Javascript. Поддержка браузерами этой новой возможности достаточно высока, используйте сервис caniuse, чтобы узнать какие браузеры ее поддерживают. Обратите внимание, что если вы загружаете файл модуля путем помещения в значение атрибута src прямой ссылки на локальный файл, то столкнетесь со следующей ошибкой:
Это следствие политики CORS, согласно которой модули должны использоваться на серверной стороне, которая настраивается локально на компьютере с помощью http-сервера или в сети Интернет с помощью хостинг-провайдера.
Модули отличаются от обычных скриптов несколькими существенными особенностями:
Модули по-прежнему широко используются при работе со сборщиками кода такими, как Webpack, для обеспечения поддержки браузерами дополнительных возможностей языка, а также доступны для использования непосредственно в браузерах.
Именованный экспорт
Как уже говорилось ранее, использование синтаксиса export позволяет выборочно импортировать именованные инструкции кода, которые экспортируются из модуля по имени. Например, рассмотрим следующую упрощенную версию файла functions.js :
Этот код позволяет импортировать функции sum и difference по их имени, используя фигурные скобки:
Используя * синтаксис, вы можете импортировать содержимое всего модуля в составе одного объекта. В этом случае функции sum и difference будут доступны как методы объекта mathFunctions :
Теперь все экспортируемое можно успешно импортировать. Другой вид экспорта, с которым мы познакомимся в следующем разделе, известен как экспорт по умолчанию.
Экспорт по умолчанию
Перепишем код файла functions.js в следующем виде:
В файле script.js импортируем функцию sum по умолчанию, как это показано в коде ниже:
По этой причине рекомендуется использовать именованный экспорт из модуля, так как экспорт по умолчанию не требует идентификатора для передачи в него экспортируемого кода. Экспортом же по умолчанию обычно экспортируются примитивные значения или анонимные функции. Ниже приведен пример объекта, экспортируемого по умолчанию:
Импортировать объект book можно следующим образом:
Точно так же в следующем примере демонстрируется экспорт по умолчанию анонимной стрелочной функции:
Функция импортируется из модуля файла script.js следующим образом:
Именованный экспорт и экспорт по умолчанию можно использовать совместно друг с другом, как в модуле из примера ниже, который экспортирует два именованных значения и одно значение (функцию) по умолчанию:
Импортируются эти переменные и функция следующим образом:
Теперь в скрипте доступны как значение по умолчанию, так и именованные значения.
Вывод
Экспорт и импорт
Директивы экспорт и импорт имеют несколько вариантов вызова.
В предыдущей главе мы видели простое использование, давайте теперь посмотрим больше примеров.
Экспорт до объявления
Мы можем пометить любое объявление как экспортируемое, разместив export перед ним, будь то переменная, функция или класс.
Например, все следующие экспорты допустимы:
Обратите внимание, что export перед классом или функцией не делает их функциональным выражением. Это всё также объявление функции, хотя и экспортируемое.
Большинство руководств по стилю кода в JavaScript не рекомендуют ставить точку с запятой после объявлений функций или классов.
Поэтому в конце export class и export function не нужна точка с запятой:
Экспорт отдельно от объявления
Также можно написать export отдельно.
Здесь мы сначала объявляем, а затем экспортируем:
…Или, технически, мы также можем расположить export выше функций.
Импорт *
Обычно мы располагаем список того, что хотим импортировать, в фигурных скобках import <. >, например вот так:
На первый взгляд «импортировать всё» выглядит очень удобно, не надо писать лишнего, зачем нам вообще может понадобиться явно перечислять список того, что нужно импортировать?
Для этого есть несколько причин.
Современные инструменты сборки (webpack и другие) собирают модули вместе и оптимизируют их, ускоряя загрузку и удаляя неиспользуемый код.
Предположим, мы добавили в наш проект стороннюю библиотеку say.js с множеством функций:
Теперь, если из этой библиотеки в проекте мы используем только одну функцию:
…Тогда оптимизатор увидит, что другие функции не используются, и удалит остальные из собранного кода, тем самым делая код меньше. Это называется «tree-shaking».
Явное перечисление импортов делает код более понятным, позволяет увидеть, что именно и где используется. Это упрощает поддержку и рефакторинг кода.
Импорт «как»
Экспортировать «как»
Давайте экспортируем функции, как hi и bye :
Теперь hi и bye – официальные имена для внешнего кода, их нужно использовать при импорте:
Экспорт по умолчанию
На практике модули встречаются в основном одного из двух типов:
По большей части, удобнее второй подход, когда каждая «вещь» находится в своём собственном модуле.
Естественно, требуется много файлов, если для всего делать отдельный модуль, но это не проблема. Так даже удобнее: навигация по проекту становится проще, особенно, если у файлов хорошие имена, и они структурированы по папкам.
Модули предоставляют специальный синтаксис export default («экспорт по умолчанию») для второго подхода.
Ставим export default перед тем, что нужно экспортировать:
…И потом импортируем без фигурных скобок:
Импорты без фигурных скобок выглядят красивее. Обычная ошибка начинающих: забывать про фигурные скобки. Запомним: фигурные скобки необходимы в случае именованных экспортов, для export default они не нужны.
Технически в одном модуле может быть как экспорт по умолчанию, так и именованные экспорты, но на практике обычно их не смешивают. То есть, в модуле находятся либо именованные экспорты, либо один экспорт по умолчанию.
Например, всё это – полностью корректные экспорты по умолчанию:
Это нормально, потому что может быть только один export default на файл, так что import без фигурных скобок всегда знает, что импортировать.
Без default такой экспорт выдал бы ошибку:
Имя «default»
Например, чтобы экспортировать функцию отдельно от её объявления:
Или, ещё ситуация, давайте представим следующее: модуль user.js экспортирует одну сущность «по умолчанию» и несколько именованных (редкий, но возможный случай):
Вот как импортировать экспорт по умолчанию вместе с именованным экспортом:
Довод против экспортов по умолчанию
Именованные экспорты «включают в себя» своё имя. Эта информация является частью модуля, говорит нам, что именно экспортируется.
Именованные экспорты вынуждают нас использовать правильное имя при импорте:
…В то время как для экспорта по умолчанию мы выбираем любое имя при импорте:
Так что члены команды могут использовать разные имена для импорта одной и той же вещи, и это не очень хорошо.
Обычно, чтобы избежать этого и соблюсти единообразие кода, есть правило: имена импортируемых переменных должны соответствовать именам файлов. Вот так:
Это также немного упрощает реэкспорт (смотрите ниже).
Реэкспорт
Зачем это нужно? Рассмотрим практический пример использования.
Представим, что мы пишем «пакет»: папку со множеством модулей, из которой часть функциональности экспортируется наружу (инструменты вроде NPM позволяют нам публиковать и распространять такие пакеты), а многие модули – просто вспомогательные, для внутреннего использования в других модулях пакета.
Структура файлов может быть такой:
Так как нужная функциональность может быть разбросана по модулям нашего пакета, мы можем импортировать их в auth/index.js и тут же экспортировать наружу.
Реэкспорт экспорта по умолчанию
При реэкспорте экспорт по умолчанию нужно обрабатывать особым образом.
export User from ‘./user.js’ не будет работать. Казалось бы, что такого? Но возникнет синтаксическая ошибка!
Чтобы реэкспортировать экспорт по умолчанию, мы должны написать export
export * from ‘./user.js’ реэкспортирует только именованные экспорты, исключая экспорт по умолчанию.
Если мы хотим реэкспортировать и именованные экспорты и экспорт по умолчанию, то понадобятся две инструкции:
Такое особое поведение реэкспорта с экспортом по умолчанию – одна из причин того, почему некоторые разработчики их не любят.
Итого
Вы можете проверить себя, читая их и вспоминая, что они означают:
Мы можем поставить import/export в начало или в конец скрипта, это не имеет значения.
То есть, технически, такая запись вполне корректна:
На практике импорты, чаще всего, располагаются в начале файла. Но это только для большего удобства.
Обратите внимание, что инструкции import/export не работают внутри <. >.
Условный импорт, такой как ниже, работать не будет:
…Но что, если нам в самом деле нужно импортировать что-либо в зависимости от условий? Или в определённое время? Например, загрузить модуль, только когда он станет нужен?
Мы рассмотрим динамические импорты в следующей главе.
import
Обратная совместимость может быть обеспечена с помощью атрибута nomodule тега script.
Динамический импорт полезен в ситуациях, когда вы хотите загрузить модуль условно или по требованию. Статическая форма предпочтительна для загрузки начальных зависимостей и может быть более полезна для инструментов статического анализа и tree shaking.
Внимание: На данный момент эта функциональность только начинает поддерживаться браузерами. Полноценная реализация присутствует во многих транспайлерах, таких как TypeScript и Babel, а также в сборщиках, например, в Rollup и Webpack.
Синтаксис
Описание
Параметр name это имя локального объекта, который будет использован как своего рода пространство имён, ссылающееся на импортируемые значения. Параметры export определяют отдельные именованные значения, в то время как import * as name импортирует все значения. Примеры ниже объясняют синтаксис.
Импорт всего содержимого модуля
Импорт единичного значения из модуля
Определённое ранее значение, названное myExport, которое было экспортировано из модуля my-module либо неявно (если модуль был экспортирован целиком), либо явно (с использованием инструкции export ), позволяет вставить myExport в текущую область видимости.
Импорт нескольких единичных значений
Этот код вставляет оба значения foo и bar в текущую область видимости.
Импорт значений с использованием более удобных имён
Вы можете переименовать значения, когда импортируете их. Например, этот код вставляет shortName в текущую область видимости.
Переименование нескольких значений в одном импорте
Код, который импортирует несколько значений из модуля, используя более удобные имена.
Импорт модуля для использования его побочного эффекта
Импорт всего модуля только для использования побочного эффекта от его вызова, не импортируя что-либо. Это запускает глобальный код модуля, но в действительности не импортирует никаких значений.
Импорт значения по умолчанию
Есть возможность задать дефолтный export (будь то объект, функция, класс или др.). Инструкция import затем может быть использована для импорта таких значений.
Простейшая версия прямого импорта значения по умолчанию:
Возможно также использование такого синтаксиса с другими вариантами из перечисленных выше (импорт пространства имён или именованный импорт). В таком случае, импорт значения по умолчанию должен быть определён первым. Для примера:
Импорт переменных
Если вы импортируете переменные, то в данной области видимости они ведут себя как константы.
Такой код выведет ошибку:
my-module.js
main.js
Для импорта можно воспользоваться объектом в котором хранятся эти переменные.
Такой код будет рабочим:
my-module.js
main.js
Учитывая, что import хранит именно ссылки на значения, экспортированные из внешнего модуля, то это можно использовать как замыкания.
Динамический импорт
Ключевое слово import можно использовать как функцию для динамического импорта модулей. Вызов import() возвращает Promise.
Как следствие возврата Promise, с динамическим импортом можно использовать ключевое слово await
Примеры
Импорт из вспомогательного модуля для помощи в обработке запроса AJAX JSON.
Модуль: file.js
Основной код: main.js
Динамический импорт
Модули в JavaScript
Фронтенд-разработчики каждый день используют модули. Это может быть функция из локального файла или сторонняя библиотека из node_modules. Сегодня я кратко расскажу об основных модульных системах в JavaScript и некоторых нюансах их использования.
Синтаксис систем модулей
В современном JavaScript осталось два основных стандарта модульных систем. Это CommonJS, которая является основной для платформы Node.js, и ESM (ECMAScript 6 модули), которая была принята как стандарт для языка и внесена в спецификацию ES2015.
История развития модульных систем JavaScript хорошо описана в статьях «Эволюция модульного JavaScript» и «Путь JavaScript-модуля».
Если вам хорошо известен весь синтаксис модульных систем ESM и CommonJS, то можно пропустить следующую главу.
ESM-модули
Именованный импорт/экспорт
export можно использовать в момент объявления функции, переменной или класса:
Для больших модулей удобнее использовать группированный экспорт, это позволяет наглядно увидеть все экспортируемые сущности внутри модуля:
Импорт/Экспорт по умолчанию
В случае, когда из файла модуля экспортируется только одна сущность, удобнее использовать экспорт по умолчанию. Для этого необходимо добавить default после инструкции export :
Импорт модуля в случае экспорта по умолчанию:
Дополнительные возможности
Переименование. Для изменения имени метода в момент импорта/экспорта существует инструкция as :
Импорт этой функции будет доступен только по новому имени:
Переименование в момент импорта:
Этот синтаксис полезен для случаев, когда имя импортируемой части уже занято. Также можно сократить имя функции/переменной/класса, если она часто используется в файле:
Инициализация модуля без импорта его частей. Используется, когда необходимо выполнить импорт модуля для выполнения кода внутри него, но не импортировать какую-либо его часть:
Импорт всего содержимого модуля. Можно импортировать всё содержимое модуля в переменную и обращаться к частям модуля как к свойствам этой переменной:
Такой синтаксис не рекомендуется использовать, сборщик модулей (например, Webpack) не сможет корректно выполнить tree-shaking при таком использовании.
Реэкспорт. Существует сокращенный синтаксис для реэкспорта модулей. Это бывает полезно, когда нужно собрать модули из разных файлов в одном экспорте:
при таком реэкспорте наименования частей модуля будут сохраняться, но можно изменять их с помощью инструкции as :
Аналогичным способом можно реэкспортировать значения по умолчанию:
Использование модулей в браузере
Рассмотрим на примере небольшого проекта.
Импорт модуля внутри index.html:
По атрибуту type=»module» браузер понимает, что экспортирует файл с модулями, и корректно его обработает. Стоит отметить, что пути импорта, указанные в main.js (./dist/module1 и ./dist/module2), будут преобразованы в абсолютные пути относительно текущего расположения, и браузер запросит эти файлы у сервера по адресам /dist/module1 и /dist/module2 соответственно. Практического применения у этой возможности не так много, в основном в проектах используется сборщик (например Webpack), который преобразует ESM-модули в bundle. Однако использование ESM-модулей в браузере может позволить улучшить загрузку страницы за счет разбиения bundle-файлов на маленькие части и постепенной их загрузки.
CommonJS
В CommonJS cуществует что-то схожее с импортом по умолчанию, для этого необходимо просто присвоить module.exports значению экспортируемой функции:
Сохранение значения в exports напрямую, в отличие от именованного экспорта, не будет работать:
Стоит обратить внимание, что если были экспортированы части модуля, они затрутся и будет экспортировано только последнее значение module.exports :
Импорт. Для импорта необходимо воспользоваться конструкцией require() и указать путь до модуля:
Можно воспользоваться деструктуризацией и получить значение необходимой функции сразу после импорта:
Работа с модулями в Node.js
Поддержка ESM-модулей
До недавнего времени Node.js поддерживал только CommonJS, но с версии 13.2.0 команда разработчиков анонсировала поддержку ESM (с версии 8.5.0 поддержка модулей ECMAScript 6 была скрыта за экспериментальным флагом). Подробно о том, как работать с модулями ECMAScript 6 в Node.js, можно прочитать в анонсе команды разработчиков Node.js.
Поиск модулей
Все относительные пути, начинающиеся c ‘./’ или ‘../’ будут обрабатываться только относительно рабочей папки проекта. Пути с ‘/’ будут обрабатываться как абсолютные пути файловой системы. Для остальных случаев Node.js начинает поиск модулей в папке проекта node_modules (пример: /home/work/projectN/node_modules). В случае, если интересующий модуль не был найден, Node.js поднимается на уровень выше и продолжает свой поиск там. И так до самого верхнего уровня файловой системы. Поиск необходимой библиотеки будет выглядеть следующим образом:
Дополнительные свойства у module и require
У module и require есть дополнительные свойства, которые могут быть полезны.
module.id — уникальный идентификатор модуля. Обычно это полностью определенный путь до модуля.
module.children — объект, содержащий модули, которые импортированы в текущем файле. Ключами объекта являются module.id :
require.cache — представляет из себя объект с информацией о каждом импортированном модуле. Если при импорте модуля Node.js находит его в кеше, код модуля не будет выполняться повторно, а экспортируемые сущности будут взяты из закешированного значения. При необходимости повторного «чистого» импорта модуля необходимо сбросить закешированное значение, удалив его из кеша:
Что происходит в момент импорта ES-модуля
В момент выполнения файла Javascript-движок выполняет несколько этапов загрузки модулей:
Структура данных, содержащая информацию о модуле (уникальный идентификатор, список зависимостей и состояния всех экспортируемых значений) называется Module Records.
При выполнении скрипта строится граф зависимостей и создается запись по каждому импортируемому модулю внутри него. В момент каждого импорта, вызывается метод Evaluate() внутри модуля Module Records. При первом вызове этой функции выполняется сценарий для получения и сохранения состояния модуля. Подробнее об этом процессе можно прочитать в статье «Глубокое погружение в ES-модули в картинках».
Что происходит при повторном импорте модуля
Но остался открытым вопрос, создаётся ли новая сущность Module Records при повторном импорте? Например в данном случае:
За получение Module Records для каждого import отвечает метод HostResolveImportedModule, который принимает два аргумента:
В спецификации говорится, что для одинаковых парах значений referencingScriptOrModule и specifier возвращается один и тот же экземпляр Module Records.
Рассмотрим еще один пример, когда один и тот же модуль импортируется в нескольких файлах:
Multiple different referencingScriptOrModule, specifier pairs may map to the same Module Record instance. The actual mapping semantic is host-defined but typically a normalization process is applied to specifier as part of the mapping process. A typical normalization process would include actions such as alphabetic case folding and expansion of relative and abbreviated path specifiers
Таким образом, даже если referencingScriptOrModule отличается, а specifier одинаков, может быть возвращен одинаковый экземпляр Module Records.
Однако этой унификации не будут подвержены импорты с дополнительными параметрами в specifier :
Циклические зависимости
При большой вложенности модулей друг в друга может возникнуть циклическая зависимость:
Для наглядности, эту цепочку зависимостей можно упростить до:
ES-модули нативно умеют работать с циклическими зависимостями и корректно их обрабатывать. Принцип работы подробно описан в спецификации. Однако, ESM редко используются без обработки. Обычно с помощью транспилятор (Babel) сборщик модулей (например, Webpack) преобразует их в CommonJS для запуска на Node.js, или в исполнямый скрипт (bundle) для браузера. Циклические зависимости не всегда могут быть источником явных ошибок и исключений, но могут стать причиной некорректного поведения кода, которое трудно будет отловить.
Есть несколько хаков, как можно обходить циклические зависимости для некоторые ситуаций, но лучше просто не допускать их возниковения.
Заключение
В этой статье я собрал всю основную информацию о модульных системах в Javascript, чтобы у читателя не осталось пробелов относительно того, как их использовать и как они работают. Надеюсь, у меня это получилось, и статья оказалась вам полезной. Буду рад обратной связи!
Как включить файл JavaScript в другой файл JavaScript?
есть ли что-то в JavaScript, как @import в CSS, который позволяет включить файл JavaScript внутри другого файла JavaScript?
30 ответов
в старых версиях JavaScript не было импорта, включения или требования, поэтому было разработано множество различных подходов к этой проблеме.
но с 2015 года (ES6) JavaScript имеет модули ES6 стандарт для импорта модулей в узел.js, который также поддерживается большинство современных браузеров.
для совместимости со старыми браузерами, построить и/или transpilation инструменты могут быть используемый.
модули ES6
Если кто-то ищет что-то более продвинутое, попробовать RequireJS. Вы получите дополнительные преимущества, такие как управление зависимостями, лучший параллелизм и избежание дублирования (т. е. получение сценария более одного раза).
Вы можете записать свои файлы JavaScript в» модули», а затем ссылаться на них как на зависимости в других сценариях. Или вы можете использовать RequireJS как простое решение «go get this script».
определить зависимости как модули:
некоторых-зависимость.js
реализация.js ваш» основной » файл JavaScript, который зависит от некоторых-зависимость.js
RequireJS загружает простые файлы JavaScript, а также более определенные модули. Он оптимизирован для использования в браузере, в том числе в Интернете Рабочий, но его можно использовать в других JavaScript окружающая среда, как Носорог и узел. Он реализует асинхронный модуль API.
RequireJS использует простые теги скриптов для загрузки модулей / файлов, поэтому он должен позвольте для легкой отладки. Его можно использовать просто для загрузки существующего Файлы JavaScript, так что вы можете добавить его в существующий проект без необходимость переписывать файлы JavaScript.
там на самом деле is способ загрузки файла JavaScript не асинхронно, поэтому вы можете использовать функции, включенные в ваш недавно загруженный файл сразу после его загрузки, и я думаю, что он работает во всех браузерах.
вам нужно использовать jQuery.append() на элемент вашей страницы, то есть:
однако этот метод также имеет проблему: если ошибка происходит в импортированном файле JavaScript, Палий (а также Консоль ошибок Firefox и Инструменты Разработчика Chrome также) сообщит о своем месте неправильно, что является большой проблемой, если вы используете Firebug для отслеживания ошибок JavaScript (я делаю). Firebug просто не знает о недавно загруженном файле по какой-то причине, поэтому, если в этом файле возникает ошибка, она сообщает, что она произошла в вашем main HTML-код файл, и у вас будут проблемы с выяснением реальной причины ошибки.
но если это не проблема для вы, то этот метод должен работать.
я на самом деле написал плагин jQuery под названием $.import_js(), который использует этот метод:
поэтому все, что вам нужно сделать для импорта JavaScript, это:
я сделал простой тест для этого в пример.
и сразу после включения included.js на hello() функция вызывается, и вы получаете предупреждение.
(этот ответ является ответом на комментарий e-satis).
вот обобщенная версия того, как Facebook делает это для их вездесущей кнопки Like:
если он работает для Facebook, он будет работать для вас.
большинство решений, показанных здесь, подразумевают динамическую нагрузку. Вместо этого я искал компилятор, который собирает все зависящие файлы в один выходной файл. То же самое, что меньше/Сасс препроцессоры имеют дело с CSS @import at-rule. Поскольку я не нашел ничего достойного такого рода, я написал простой инструмент для решения вопроса.
src / форма / вход / тел.js
теперь мы можем запустить компилятор:
и получить объединенный файл
вы также можете собрать свой скрипт PHP:
если вы хотите, чтобы загрузить файл JavaScript использование функций импорта/включаемый файл, вы также можете определить глобальный объект и установить функции как элементы объекта. Например:
глобальные.js
file1.js
file2.js
main.js
вам просто нужно быть осторожным, когда вы включаете скрипты в HTML-файл. Порядок должен быть как в ниже:
или вместо включения во время выполнения используйте скрипт для объединения перед загрузкой.
Я использую звездочки (Я не знаю, есть ли другие). Вы создаете код JavaScript в отдельных файлах и включаете комментарии, которые обрабатываются механизмом звездочек как включенные. Для разработки вы можете включать файлы последовательно, а затем для производства, чтобы объединить их.
В случае, если вы используете Веб-Работников и хотите включить дополнительные скрипты в область рабочего, другие ответы, предоставленные о добавлении скриптов в head бирка, etc. не будет работать на вас.
к счастью, веб-работники имеют свои собственные importScripts функции который является глобальной функцией в области веб-работника, родной для самого браузера, как это является частью спецификации.
в качестве альтернативы, как второй по величине проголосовали ответ на ваш вопрос подчеркивает, RequireJS также может обрабатывать включая скрипты внутри веб-работника (вероятно, вызывая importScripts сам, но с несколькими другими полезными функциями).
у меня была простая проблема, но я был озадачен ответами на этот вопрос.
мне пришлось использовать переменную (myVar1), определенную в одном файле JavaScript (myvariables.js) в другом файле JavaScript (main.в JS).
для этого я сделал, как показано ниже:
загрузил код JavaScript в HTML-файл, в правильном порядке, myvariables.сначала js, затем main.js:
As вы видели, что я использовал переменную в одном файле JavaScript в другом файле JavaScript, но мне не нужно было включать одну в другую. Мне просто нужно было убедиться, что первый файл JavaScript загружен до второго файла JavaScript, а переменные первого файла JavaScript доступны во втором файле JavaScript автоматически.
Это спасло мой день. Надеюсь, это поможет.
обновление: смесь теперь бесплатно (offline).
обновление: смесь теперь прекращена. старые релизы смеси еще доступно
Я написал простой модуль, который автоматизирует работу импорта / включения скриптов модулей в JavaScript. Для подробного объяснения кода обратитесь к сообщению в блоге JavaScript require / import / include modules.
он отлично работает и не использует перезагрузки страниц для меня. Я пробовал метод AJAX (один из других ответов), но он, похоже, не работает так хорошо для меня.
вот объяснение того, как код работает для тех, кто любопытен: по сути, он создает новый тег скрипта (после первого) URL-адреса. Он устанавливает его в асинхронный режим, поэтому он не блокирует остальную часть кода, но вызывает обратный вызов, когда readyState (состояние содержимое для загрузки) изменяется на «loaded».
на современном языке это было бы
этот скрипт добавит файл JavaScript в начало любого другого
Я обнаружил, что, хотя все плагины попадали в тег head так, как они должны были, они не всегда запускались браузером при нажатии на страницу или обновлении.
Я обнаружил, что более надежно просто писать теги скриптов в PHP include. Вам нужно написать его только один раз, и это такая же работа, как вызов плагина с помощью JavaScript.
есть много возможных ответов на этот вопрос. Мой ответ, очевидно, основан на ряде из них. Это то, что я закончил после прочтения всех ответов.
пример:
вы правы, когда говорите, что вы можете указать Ajax для синхронного запуска или использовать XMLHttpRequest, но текущая тенденция, по-видимому, заключается в устаревании синхронных запросов, поэтому вы не можете получить полную поддержку браузера сейчас или в будущем.
Примечание: Вы должны использовать это только во время загрузки страницы, иначе вы получите пустой экран. Другими словами,всегда размещайте это перед / вне документа.готов. Я не тестировал использование этого после загрузки страницы в событии click или что-то в этом роде, но я довольно конечно, не получится.
мне понравилась идея расширения jQuery, но, очевидно, вам это не нужно.
я предполагаю, что сценарий не полностью выполняется до его document.ready событие было выполнено. (Я знаю, используя document.ready не требуется, но многие люди используют его, и регулировать это защита.)
когда загружаются дополнительные файлы document.ready обратные вызовы будут выполняться в правильном порядке. Чтобы решить эту проблему при фактической загрузке сценария, импортированный сценарий повторно импортируется и выполнение останавливается. Это приводит к тому, что исходный файл теперь имеет свой document.ready обратный вызов выполняется после любого из любых сценариев, которые он импортирует.