Введение (теория)

Начнем эту тему с аналогии с операционной системой. Почему операционная система не позволяет создавать два файла с одинаковыми именами в одном каталоге? (если мы не принимаем во внимание соглашение Linux об именовании файлов с учетом регистра) Это потому, что нелогично называть две или более вещей с одним и тем же именем в одной и той же области, и из-за этого вы не сможете отличить их от друг друга (без дополнительной информации), но вместо этого вы можете создать два файла с одинаковым именем в двух разных каталогах, и причина в том, что вы можете дифференцировать каждый из них с помощью глобальных путей. Например: /home/Nick/data.json и /home/Kate/data.json. Это приводит к древовидной структуре (теория графов) и родительско-дочерним отношениям.

Эта структура данных сделана для ясной визуализации и гибкости. Дело в том, что такая организация позволяет легко манипулировать данными (запускать на них алгоритмы).

Начиная с объявления функции, которая будет содержать все пространства имен:

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

Вставка реальных объектов пространства имен в NAMESPACE:

Мы поместим все предопределенные данные в каждый из них, которые мы хотим использовать только в этом конкретном пространстве имен:

Первое пространство имен содержит:

  • class CarКоторый создает один конкретный тип автомобиля с дизельным двигателем (в отличие от класса второго пространства имен с тем же именем, который создает другой тип автомобиля)
  • Функция logger, которая записывает данные в localStorage, а затем записывает сообщение в консоль
  • Переменная id (отмечая, что каждое пространство имен может иметь свои собственные уникальные элементы), которая используется для localStorage

Соответственно, пространство имен два содержит вещи с одинаковыми именами (чтобы указать, что мы можем использовать одни и те же имена с разной реализацией), за исключением data. Третье пространство имен я расскажу позже. Наконец, функция возвращает все три объекта.

А теперь пора волшебства!

В Visual Basic, насколько мне известно, оператор with выполняет те же функции, что и в JavaScript, и для получения дополнительной информации в python существует концепция Context Management и модуль под названием «contextlib», который включает with и в документации сказано: «Оператор with используется для обертывания выполнения блока методами, определенными диспетчером контекста». В javascriptwith оператор принимает только один аргумент - выражение. Тогда вы получите доступ ко всему, что находится внутри этого выражения. И каждый элемент (переменная, объект, класс и т. Д.), Который будет использоваться через его тело, будет ссылаться на содержимое выражения, если этот упомянутый объект существует в выражении, иначе он будет искать этот объект на один уровень выше за пределами области видимости (это вид поиска в областях специфичен для javascript, а не для Visual Basic или python).

Пример:

Первый журнал выведет 1 (а не 2, из приведенного выше глобального определения x), потому что он сначала начинает поиск в NAMESPACE.three и находит свойство x, второй журнал выводит 3, потому что он не смог найти ничего в своем собственном прицел и выскочил на один уровень вверх.

Использование одних и тех же переменных в двух разных областях:

Используйте letin пространства имен, иначе это повлияет на элементы вне области видимости

Первое пространство имен:

  • Сначала мы создаем экземпляр Car, который будет регистрироваться в конструкторе: «Namespace-One: Автомобиль был собран с дизельным двигателем»
  • Затем мы используем функцию logger, чтобы хранить данные в localStorage. logger затем записывает сообщение об успешном завершении в консоль

Второе пространство имен:

  • Первая и вторая строки такие же, как в первом пространстве имен, но относятся к разным объектам. Соответственно они записывают разные сообщения
  • В третьей строке мы записываем массив с именем data, и это первый элемент, который мы передали в качестве аргумента функции регистратора.
  • В четвертой строке я вызываю третье пространство имен (демонстрация вложенных пространств имен) и регистрирую его данные свойства, которые выводят пустой array[], потому что в этом пространстве имен был пустой массив.

Зачем использовать такое пространство имен, когда у нас есть собственный export/import?

Сначала я скажу, что если вы не работаете на сервере и используете только статические .html файлы, вы не можете использовать import, потому что такие запросы поддерживают только совместное использование ресурсов между источниками (CORS), которое должно быть указано в ответе. заголовок (заголовок ответа: Access-Control-Allow-Origin: * или Access-Control-Allow-Origin: example.com), в который сервер помещает ресурс. Читая это, вы можете посмеяться и сказать, для чего вам нужны статические html-файлы без сервера? Мой первый ответ будет: git документация. Они написаны в html-файлах, в нем вообще нет кода javascript, но проявите изобретательность и сделайте что-нибудь крутое самостоятельно. Также факт в том, что многие браузеры пока не поддерживают эту функцию.

Заключительные мысли

Подводя итог, можно сказать, что модульность дает нам возможность избежать конфликтов имен и разумно инкапсулировать элементы. Также мы не должны забывать о глобальном масштабе, чтобы не загрязнять его и сохранять как можно более чистым. Честно говоря, я никогда не видел такого использования with function. В тот момент, когда я писал, я думал, что это очень хитрый способ сделать пространство имен, поэтому я не знаю, правильный ли это способ делать это. Наконец, спасибо за чтение; Поделитесь, если тема понравилась и буду рад вашим отзывам.

Ресурсы:

  • Веб-документы MDN