Создание приложений ExtJS с помощью coon.js — Часть 2: Пакеты и параметры конфигурации

Создание приложения Rapid Sencha Ext JS

Создание приложений Ext JS с помощью coon.js — Часть 2: Пакеты и параметры конфигурации

В предыдущей части этой серии статей я дал краткое введение во фреймворк coon.js — Набор инструментов для быстрой сборки приложений «Sencha ExtJS.

Теперь пришло время представить общую идею фреймворка и пролить свет на предоставляемые им функции. В этой Части 2 мы рассмотрим управление пакетами, а в случае с coon.js это означает динамическую загрузку пакетов и предоставление параметров конфигурации для пакетов.

Все статьи из этой серии на данный момент:

• Часть 1: Создание приложений ExtJS с помощью coon.js (Введение)
• Часть 2. Пакеты и параметры конфигурации (в данный момент читает)
• Часть 3: Детали конфигурации и определение плагинов
• Часть 4: Регистрация сервисов и использование Service Locator

Жесткая проводка так 2001

Разрешение зависимостей приложений стало более удобным с введением менеджеров пакетов, таких как Composer (PHP) и NPM (в основном JavaScript).

Если вы помните ранние дни Sencha ExtJS, вы можете подумать о менеджере пакетов, который был представлен в ExtJS 4.2 и Sencha CMD 3.1 — который никогда не был по-настоящему успешным, если смотреть на него со стороны внешней зависимости. с точки зрения управления-и-централизованного-репозитория-для-стороннего-кода (фью!). Пакеты Sencha ExtJS всегда были инструментом для организации вашего кода в более мелкие, более доставляемые, повторно используемые фрагменты и могли быть хорошим способом поддержки кода компании для различных проектов, но они никогда не были достаточно гибкими для предоставления управление зависимостями стороннего кода, который мы искали много-много лет, и где Sencha явно упустил возможность прыгнуть на подножку, когда пришло время.

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

Разработка JavaScript стала намного проще с NPM. Тем не менее, Sencha по-прежнему заперт глубоко в подвале вместе с Java и Ant, и заставить все работать с Sencha CMD (от которого, очевидно, все еще зависит ExtJS), а не с Babel (для транспиляции) и NPM может быть довольно проблематично. Sencha PackageLoader делает все это более терпимым, но если вы ищете решение для динамического управления пакетами с помощью Sencha ExtJS, вам нужно добавить несколько обходных путей и проявить терпение, когда вы обдумываете сообщения об ошибках, которые в основном не дают подсказок. о том, что на самом деле пошло не так, когда sencha app build терпит неудачу с загадочным выводом консоли.

Краткое введение в Sencha Ext JS и NPM можно найти здесь:

Приложения Sencha и динамические пакеты

Загрузчик пакетов Sencha позволяет динамически загружать пакеты (отсюда и название), хотя эти пакеты должны быть связаны с приложением: предоставление информации о требованиях приложения требует дополнительных настроек. . Мало того, что app.json должен знать, какие пакеты могут (!) использоваться с вашим программным обеспечением — что противоречит варианту использования беспроводных дополнительных функций — вы также должны настройте процесс сборки с помощью определенных флагов, чтобы пакеты правильно собирались: sencha app build production --uses

Однако объединение загрузчика пакетов с NPM и некоторые настройки позволяют создавать приложения ExtJS. Здесь в игру вступает coon.js.

coon.core.app.Приложение

Чтобы уменьшить раздувание и сделать возможным динамический выбор в конечном итоге используемых пакетов, я написал специальный Ext.app.Application, способный считывать конфигурацию пакета во время запуска приложения, что упрощает подключение к процесс запуска приложения и решить, какие пакеты должны быть зарегистрированы в программном обеспечении, а также — дополнительно — загрузить информацию о пакетах из внешних файлов, предоставляя контексты времени выполнения, чтобы убедиться, что различные среды и их соответствующие конфигурации могут быть учтены.

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

Полезная нагрузка для использования этого подхода заключается в том, что разработчику необходимо переосмыслить то, как настроить приложение ExtJS: с помощью coon.js оно теперь в значительной степени состоит из — часто контекстно-независимых и автономных — пакетов (вы также можете вызвать их модули); за исключением основной функциональности и тем, конечно: они все еще привязаны к приложению.

Конфигурация

Давайте начнем с самого верха и посмотрим на конфигурацию, доступную с coon.js. Примечательно, что app.json позволяет использовать дополнительную конфигурацию, которая будет учитываться при настройке базовых пакетов — конфигурацию coon-js:

...
"name": "conjoon",
"production": {
    "coon-js": {
        "env": "prod",
        "resourcePath": "coon-js"
    }
},
"development": {
    "coon-js": {
        "env": "dev",
        "resourcePath": "coon-js"
    }
}
...

В разделы production- и development файла app.json мы добавили новое свойство с именем coon-js, которое позволяет указать конфигурацию приложения, соответствующую coon.js; мы можем прочитать это позже из Ext.manifest-объекта, доступного во время выполнения нашего Ext JS-приложения.

Итак, для чего это будет использоваться в дальнейшем? coon.js проверит среду, для которой создано приложение (здесь мы используем варианты сборки ExtJS для разработки/производства) и рассмотрим дальнейшую загрузку конфигурации с учетом env- значение, позволяющее загружать файлы конфигурации, специфичные для среды разработки или производственной среды. Например, среда разработки может содержать дополнительные параметры конфигурации для симлетов, используемых с dev-сборкой (в основном для имитации бэкэнд-API), в то время как производственная конфигурация содержит конечные точки REST и тому подобное для — ну, раскрытия информации об окружающей среде. приложения в производственном режиме. Больше вариантов использования в конце этой статьи.

resourcePath обозначает имя папки, в которой coon.js должен искать файлы конфигурации — это папка, которая должна быть доступна в каталоге resources в базовой установке приложения ExtJS. : Дополнительные параметры конфигурации Sencha для этой папки можно найти в разделе resources файла app.json.

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

Файлы конфигурации приложения

Во-первых, у вас есть глобальный файл конфигурации для конкретного приложения. Этот файл должен быть назван в честь приложения, для которого настроен coon.js, за которым следует постфикс, обозначающий среду, для которой он был создан, и обычное окончание файла .json, чтобы редакторы кода и подобные знают, как анализировать и выделять синтаксис его содержимого. Шаблон:

[имя_приложения].[среда].conf.json

В приведенном выше примере для app.json мы указали, что сокращением для производственной среды является prod, а сокращением для среда разработки — dev. Имя приложения — conjoon. Поэтому файлы конфигурации должны быть сохранены под любым из следующих имен, чтобы coon.js мог их распознать:

• "env": “dev"conjoon.dev.conf.json — конфигурация, загруженная для сборок разработки
• "env”: “prod" conjoon.prod.conf.json — конфигурация, загруженная для рабочих сборок (примечание: эта схема именования в настоящее время обсуждается, см. ссылку ниже)
• conjoon.conf.json — конфигурация загружается, если файл конфигурации для конкретной среды не найден.

Мы пока не будем вдаваться в детали возможных вариантов конфигурации, рассматриваемых coon.js — об этом позаботится 3-я часть этой серии статей — но базовый шаблон с наиболее важными разделами файла конфигурации приложения выглядит так:

{
    [application_name] : {
        "application": {},       
        "plugins": [],
        "packages": {}
    }
}

Все параметры конфигурации, указанные в разделе приложения, обычно становятся доступными во время выполнения и позже могут быть запрошены через coon.core.ConfigManager.get([application_name]) (неосведомленные пакеты могут запрашивать [application_name] с помощью класса coon.core.Environment, если необходимо: coon.core.Environment.getManifest("name")).

Конечно, для coon.core.ConfigManager доступны и другие разделы конфигурации: они являются запрашиваемыми «доменами». Например, динамические пакеты и их конфигурация (если они указаны) всегда доступны с использованием coon.core.ConfigManager.get([package_name]).

Файлы конфигурации пакета

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

Подобно app.json, информация о пакете, используемом приложением, управляемым coon.js, должна быть помещена в package.json пакета-владельца. Это нужно сделать с помощью раздела sencha в файле, поэтому конфигурация доступна позже через Ext.manifest и не конфликтует ни с одной конфигурацией NPM:

{
    
    // ... this is NPM-land
    "sencha": {
       // ... and this is Sencha-country. Most of this will
       // end up in Ext.manifest
    }
}

Опять же, мы должны указать раздел coon-js в самом файле package.json, который содержит различную информацию о пакете и о том, как он должен обрабатываться приложением-владельцем, например

• должен ли пакет автоматически загружаться при запуске приложения?
• должен ли PackageController пакета (если он доступен; это особенность Ext.app.Controller) быть зарегистрирован в качестве контроллера приложения?
• определяет ли пакет конфигурацию и где можно найти эту информацию?

Вот пример package.json из https://github.com/conjoon/extjs-app-webmail, почтового клиента для conjoon:

{
    "name": "@conjoon/extjs-app-webmail",
    "sencha": {
        "name": "extjs-app-webmail",
        "coon-js": {
            "package": {
                "autoLoad": {
                    "registerController": true
                },
                "config": {
                    // ... here be package relevant config
                }
            }
        },
        "namespace": "conjoon.cn_mail",
        "type": "code",
...

Третья часть этой серии статей будет посвящена ключевым свойствам конфигурации, а пока давайте быстро рассмотрим несколько свойств, представленных в примере: autoLoad сообщает, должен ли этот пакет загружаться при запуске приложения и может ли он быть дальнейшая настройка — в данном случае вместе с регистрацией PackageController пакета — и раздел конфигурации предоставляет всю необходимую конфигурацию для самого пакета, которую можно запрашивать во время выполнения.

Хотя предоставление всей информации о конфигурации в самом файле package.json является абсолютно допустимым, поддержка часто меняющейся конфигурации с помощью этого файла может стать проблемой: у вас также есть возможность указать отдельный файл, представляющий конфигурация пакета — удобно, если вам нужно предоставить много информации о конфигурации.

Также можно опустить конфигурацию здесь или в отдельном файле и переместить все сведения о конфигурации в файл конфигурации приложения, что упрощает редактирование нескольких конфигураций пакетов одновременно. > без необходимости управлять изменениями файлов ( git commit package.json -m “feat: add config option for project X”) в различных отдельных проектах (если ваш пакет используется в нескольких проектах). Помните шаблон файла конфигурации приложения из предыдущего раздела этой статьи? Настроим секцию packages:

{
    [application_name] : {
        "plugins": [],
        "application": {},
        "packages": {
            "extjs-app-webmail": {
                "autoLoad": {
                    "registerController": true
                },
                "config": {
                   // ... add package relevant config HERE 
                }
            }
        }
    }
}

Загрузка пакетов

Учитывая то, что мы знаем о параметрах конфигурации, давайте посмотрим, как coon.js решает, следует ли загружать пакет динамически.

Прежде всего, мы должны позаботиться о двух вещах: пометить пакет как пакет coon.js и сообщить нашему приложению о требованиях к пакету в разделе uses в нашем app.json. В то время как последнее является необходимым требованием для внутреннего загрузчика пакетов ExtJS (подробнее о внутреннем устройстве можно прочитать здесь), необходимо пометить пакет как пакет coon.js, чтобы пакет можно было идентифицировать и рассматривать как пакет. содержащий дополнительную, еще не загруженную конфигурацию.

Весь процесс упрощен:
1) Приложение загружается и загружает требования

2) coon.js подключается к процессу, ищет и анализирует доступный package.json из любого пакета, доступного для приложения.

3) если пакет помечен как пакет coon.js (т.е. имеет раздел coon-js), конфигурация для этого пакета будет найдена и проанализирована

4) если PackageController должен быть зарегистрирован, он регистрируется в приложении

5) launch()

Для того, чтобы это работало, разработчик должен расшириться от coon.core.app.Application, который является специфическим для Ext.app.Application — его onProfilesReady затем инициализирует пакеты и их конфигурацию и настроит все необходимые контроллеры, дополнительно настроит и подготовит все плагины, которые следует использовать. с приложением.

Как упоминалось ранее, пакеты, которые могут быть использованы позже, должны быть представлены с помощью uses — свойства конфигурации в app.json — это позволяет позже найти метаданные пакетов в Ext.manifest-объекте.

Простые варианты использования

Вот несколько вариантов использования, которые дадут вам представление о том, как использовать динамическую загрузку и настройку пакетов с помощью coon.js.

Различные пакеты для среды разработки и производства

Если вы знакомы с созданием фронтенд-систем, вы часто сталкиваетесь с бэкэнд-системами Шрёдингера — бэкендами, которые нужны приложению, но никто не знает, существуют ли они (кроме, возможно, разработчика, ответственного за его реализацию)! Требуется для вашей работы и для обработки входящих и исходящих данных, предопределенная структура данных и некоторые фиктивные данные подходят для настройки POC и тестов, но когда вам нужно протестировать свой интерфейс в более живых условиях, вам нужно больше настоящих данных. .
Для этой цели существует Ext.ux.ajax.SimManager, и я не могу достаточно часто утверждать, что ваш проект должен использовать его напрямую с самого начала — в прошлом это сэкономило нашей компании драгоценное время. SimManager позволяет управлять фиктивными конечными точками данных служб для вашего программного обеспечения во время разработки: вы можете связывать все свои запросы, как будто они действительно существуют в вашем коде, но после запроса вы на самом деле не подключаетесь к серверный API через http: вместо этого SimManager заботится о перенаправлении запросов к внутренним классам JavaScript, которые затем будут искать любые данные, ранее определенные с учетом определенного шаблона URL. (Используя React, вы можете вернуться к замечательному проекту Mirage; вы можете наверстать упущенное в теме мокирования API, прочитав эту статью от @shashiparakramasinghe).

Используя coon.js, мы можем просто присоединять и отсоединять симлеты в нашей среде разработки, соответствующей производственной среде. В нашем разделе разработки файла app.json мы определяем те пакеты, которые представляют симлеты в массиве uses—, а также при необходимости указываем конфигурацию URL в связанной конфигурации. PackageController, который автоматически загружается в приложение, затем позаботится о настройке и регистрации симлетов во внутреннем SimManager ExtJS. Учитывая параметры конфигурации, симлеты также могут существовать в производственных сборках — изменение значения в файле конфигурации позволяет легко включать или отключать их по отдельности.

Включение/отключение пакетов для разных сборок

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

Функциональность горячей замены

Вы когда-нибудь мечтали о добавлении/удалении пакетов в приложение Sencha без необходимости его полной перестройки? Используя команды сборки пакетов Sencha CMD, мы можем создавать пакеты и помещать их в производственную сборку приложения Sencha, созданного с помощью coon.js, или полностью удалять любой из них. Это позволяет пользователям просто добавлять и удалять сторонние пакеты самостоятельно, не затрагивая какую-либо существующую кодовую базу (за исключением Ext.manifest, который должен знать о дополнительных пакетах, доступных для программного обеспечения. Но этого достаточно). для другой статьи…)

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

Ранее я писал об охоте за ошибками: Ext JS Simlets и опускал код состояния:

Соединять

Торстен Зуков-Хомберг | Гитхаб| Твиттер| Ютуб| Инстаграм