AXForum  
Вернуться   AXForum > Блоги > CRM, SharePoint и Черная Магия
NAV
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

Добро пожаловать в мой блог! Изначально он не задумывался как блог CRM разработчика, но жизнь сама внесла нужные коррективы. Тут я публикою все свои наблюдения относительно обозначенных в заголовке систем. Если Вы найдете в нем что-то интересное для Вас, как для заказчика, то буду рад сотрудничать с Вами! В моей компетенции 100% задач по MS CRM 3.0/4.0/2011:
  • Консалтинг
  • Проектирование
  • Разработка
  • Обучение


MVP 2010, 2011
Оценить эту запись

Динозавр осваивает Modern Web - Часть пятая

Запись от Артем Enot Грунин размещена 27.10.2017 в 13:32
Теги modernweb, react

Часть пятая - Как работает сборка?

Предыдущая статья серии: Динозавр осваивает Modern Web - Часть четвертая

В прошлой статье мы с вами успешно собрали и разместили в CRM наше первое приложение на React. Теперь осталось понять почему все так сложно и где там был сам реакт. В общем-то это нормальная реакция человека, который только начал во все это погружаться. Непривычные инструменты, новый синтаксис и идеология собьют с толку кого угодно. Но, не все так плохо. Давайте разбираться как все это работает!

Для это вернемся в студию и посмотрим из чего состоит наш проект. Начнем в порядке значимости - с файла package.json. Не путать с packages.config! У них похожи не только названия, но и назначения. packages.config - это список NuGet пакетов, которые используются в решении, а package.json - это, в некотором роде, конфигурация NPM (менеджера пакетов Node):

Название: 01 explorer.png
Просмотров: 5933

Размер: 23.6 Кб

В корне этого файла описывается информация о нашем пакете на тот случай если мы захотим разместить его в NPM. Это, пожалуй, ключевое отличие от NuGet каждый проект - кандидат сдать утилитой в другом проекте. Далее, идут разделы dependencies, devDependencies и scripts:

Нажмите на изображение для увеличения
Название: 02 package.png
Просмотров: 1088
Размер:	33.7 Кб
ID:	414

Раздел dependencies - аналог Reference в .NET. Тут содержится перечень своих, или сторонних "библиотек", которые нужны для работы нашего приложения. В данном случае, количество зависимостей минимально - это библиотеки react и react-dom, которые всегда идут в паре. Насколько понял, их разделили, чтобы независимо развивать React Native - библиотеку для работы с мобильными приложениями. Здесь же мы видим библиотеку react-scripts-ts, которая, вообще-то инструмент разработки, а не библиотека, которую мы используем в своем решении, но разработчикам должно быть виднее. Видимо какие-то ее части нужны для работы приложения, которое компилируется по этому шаблону.

Раздел devDependencies похож на предыдущий, с той лишь разницей, что он содержит компоненты, которые не войдут в приложение, но используются как инструментарий для его создания. В данном случае мы видим несколько библиотек @types. Зачем они нужны мы разберем чуть позже. Если кратко, это некий аналог h. -(header) файлов в C/C++, но для TypeScript. Они добавляют недостающие описания типов для библиотек которые написаны на чистом JS, чтобы лучше работала подсветка синтаксиса, а компилятор TypeScript мог лучше отлеживать типы данных.

Раздел "scripts" отвечает за ту магию, которая выполняется командами start и build, а также теми, которые мы еще не использовали. Команда start является стандартной, поэтому может использоваться без инструкции run, а остальные должны использоваться с ней. Например:

X++:
npm run test
Обратите внимание, что все команды выполняются при помощи инструмента react-scripts-ts. Именно он делает за нас всю работу по горячей загрузке обновленных файлов во время отладки и сборку готового решения по команде build.

Идем далее. Папка "node modules". Как нетрудно догадаться, сюда будут складываться все пакеты из разделов dependencies и devDependencies. Нужно отметить, что студия имеет встроенную поддержку NPM и сама умеет "читать" изменения в package.json. Если мы добавим какой-то модуль, он автоматически будет скачан и размещен в каталоге node modules. Важный момент! Версия Node, которая входит в состав студии может быть устаревшей. Это может приводить к проблемам при загрузке пакетов, или при запуске команд из окна студии.

Чтобы этого избежать, щелкните правой кнопкой на файле package.json и выберите Configure External Tools:

Нажмите на изображение для увеличения
Название: 03 configure.png
Просмотров: 1191
Размер:	24.2 Кб
ID:	415

В открывшемся окне, нужно переместить PATH на верхнюю строчку:

Нажмите на изображение для увеличения
Название: 04 path.png
Просмотров: 1148
Размер:	38.9 Кб
ID:	416

Теперь студия будет использовать ту же версию Node, которую мы используем в консоли.

Следующие два файла, которые отвечают за конфигурацию решения - это tsconfig.json и tslint.json. Первый из них - файл конфига компилятора TypeScript. Он отсутствует в версии create-react-app c использованием Java Script. Второй - настройки другого специфичного инструмента - линтера. Изначально линт - это программа проверки исходных кодов для языка C на предмет типовых ошибок и корявых конструкций, типа if (a=1). Позже, линтерами стали называть весь класс подобных программ. В большинстве случаев, вы не будете изменять эти конфиги. Оба этих инструмента поддерживаются студией, так что все ошибки компиляции, или варнинги линтера вы увидите в консоли ошибок:

Название: 05 lint.png
Просмотров: 5856

Размер: 18.0 Кб

Все прочие элементы решения отвечают за его наполнение, а не настройку. Подробно назначение каждого из них описано в документации по create-react-app: https://github.com/facebookincubator...-configuration, так что я расскажу лишь о них лишь кратко. По концепции решения, все исполняемые файлы должны быть расположены в каталоге src. Именно там сборщик будет искать наши TypeScript файлы для компиляции. В папке public должны быть расположены статичные "асеты" проекта, такие как картинки, библиотеки, которые недоступны через NPM и пр. файлы, которые не нужно "компилировать". Так же, тут располагается шаблон стартовой страницы index.html над которым тоже поработает сборщик. В частности, в страницу автоматически будут добавлены ссылки на скомпилированные скрипты.

Давайте теперь посмотрим, как выглядит сам сборщик. Если вы пробовали что-то делать по мануалам из интернета, вы наверняка провели несколько увлекательных минут с настройкой вебпака, который мы пока что совершенно не касались. Что ж, самое время оценить тот колоссальный труд, который проделала команда разработки create-react-app, чтобы избавить нас от необходимости настраивать сборку от проекта к проекту.

Для этого, откроем консоль в корне решения и выполним

X++:
npm run eject
Эта операция необратима, о чем нас честно предупредят. Возможно вы захотите сохранить резервную копию проекта до ее выполнения.

В итоге мы увидим, что в наш проект добавилось много всего нового:

Нажмите на изображение для увеличения
Название: 06 eject.png
Просмотров: 1084
Размер:	53.1 Кб
ID:	418

Изменился и package.json. В него добавилось много новых зависимостей, которые заботливо прятал от нас пакет react-scripts-ts. Изменилась и секция со скриптами. Мы по-прежнему можем выполнить build и start, но теперь вместо react-scripts-ts будут выполняться локальные скрипты в каталоге проекта.

Давайте теперь обновим каталог решения в Solution Explorer и перейдем в новый каталог "config" где находится сердце нашего сборщика - файл конфигурации webpack:

Название: 07 webpack.png
Просмотров: 5933

Размер: 19.0 Кб

В одной из прошлых статей этой серии, мы выяснили, что сборка модерн веб приложений, как правило делается с использованием этого инструмента. Сразу скажу, что конфигурация не обязана быть такой монструозной. Чаще всего достаточно конфига на 5-10 строчек, но тут мы видим высший пилотаж! Почти 300 строк хитрой конфигурации, оптимизации и компоновки решения, на выходе из которой мы и получим наши уродливые имена файлов. Впрочем, теперь мы можем все изменить!

Давайте откроем webpack.config.prod.js и найдем в нем следующий фрагмент:

Нажмите на изображение для увеличения
Название: 08 loaders.png
Просмотров: 1172
Размер:	30.5 Кб
ID:	420

Загрузчики (loaders) - это элемент процесса сборки, который отвечает за выбор инструмента "компиляции" для каждого конкретного файла. Давайте уберем вхождение блока [hash:8] во всех загрузчиках, чтобы убрать хеши из имен файлов. Дополнительно придется поискать по ключевому слову hash, чтобы найти другие места конфига, где они могут использоваться, например:

const cssFilename = 'static/css/[name].[contenthash:8].css';
filename: 'static/js/[name].[chunkhash:8].js',
chunkFilename: 'static/js/[name].[chunkhash:8].chunk.js',

Так же следует закомментировать подключение плагина SWPrecacheWebpackPlugin, так как он, в любом случае не будет работать в CRM.

Если все было сделано правильно, мы получим приемлемый "статичный" билд:

Название: 09 static.png
Просмотров: 5933

Размер: 14.1 Кб

Не забудьте убрать хэши из имен файлов в spkl.json, так как теперь мы в них не нуждаемся.

И вот мы, наконец, разобрались как создать, скомпилировать и опубликовать решение в CRM. Осталось понять кто такие React и TypeScript и чем они могут быть нам полезны. Об этом я расскажу в следующих статьях серии.
Размещено в CRM
Просмотров 286180 Комментарии 0
Всего комментариев 0

Комментарии

 


Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 07:46.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.