Ещё один пост о сборке front-end проекта
Я потратил прилично времени на структуризацию и автоматизацию сборки фронта. Задача это интересная и стоит того, чтобы о ней рассказать.
Вступительное
Чтобы было удобней следить за мыслью, сразу кидаю ссылку на репозиторий с шаблоном проекта: github.com/alexfedoseev/js-app-starter
Убедитесь, что установлен npm.
Установите необходимые глобальные модули (если ещё не установлены):
Сделайте форк репозитория.
Установите зависимости проекта (исполнять в корне репозитория):
Соберите проект в development окружении и запустите локальный сервер:
Откройте браузер и перейдите на lvh.me:3500
Структура проекта
.gitignore & .npmignore
Внутри этих файлов находится список того, что будет игнорироваться git и npm при коммитах/паблишах.
node_modules/
В эту директорию падают все модули, которые мы установим через npm.
npm-shrinkwrap.json
Я не держу в репозитории содержимое node_modules/. Вместо этого лочу все зависимости через этот файл. Он генерируется автоматически командой: `npm shrinkwrap`.
package.json
Это файл с глобальными настройками проекта. К нему ещё вернемся.
gulpfile.js
Обычно тут хранятся все таски для сборки проекта, но в нашем случае он просто определяет значение переменной окружения и пробрасывает нас дальше в папку с gulp-тасками.
lib/gulp/
Здесь храним все настройки и задачи сборщика.
|— config.js
Выносим настройки для всех тасков в отдельный файл, чтобы минимизировать правку самих тасков.
|— helpers/
Вспомогательные методы сборщика.
|— tasks/
И сами gulp-таски.
src/
Исходники проекта.
public/
Результат сборки. Абсолютно всё содержимое этой папки генерируется сборщиком и перед каждой новой сборкой она полностью очищается, поэтому тут никогда и ничего не храним.
dist/
Иногда я пишу opensource-модули. В этой папке после сборки оказываются обычная и минифицированная версии написанной js-библиотеки. При этом директория public/ используется как хранилище для демки. Если вы делаете обычный сайт или страницу приземления, то оно не понадобится.
Настройка проекта
package.json
Это файл, в котором хранятся глобальные настройки проекта.
Подробное описание его внутренностей можно посмотреть тут: browsenpm.org/package.json
Ниже я остановлюсь только на некоторых важных частях.
Консольные команды
В package.json мы можем прописать алиасы для консольных команд, которые будем часто выполнять в процессе разработки.
Production сборка
Когда мы готовы релизить проект — делаем production-сборку.
Переходим к Gulp. Структура тасков взята из сборщика от Dan Tello.
Перед тем, как нырнуть, небольшой комментарий по порядку выполнения обычного gulp-таска:
Теперь разберемся что и в каком порядке будем собирать.
Development сборка
`npm start` запускает команду `gulp`. Что происходит дальше:
Production сборка
С ней всё проще. `npm run build` запускает команду `gulp build`, которая очищает целевые папки, линтит js-код, собирает спрайты и после этого собирет проект (без sourcemaps). Код с комментариями выше.
Файл конфигураций gulp-тасков
Все основные конфигурации тасков вынесены в отдельный файл lib/gulp/config.js:
Сборка HTML
Для шаблонизации используем Jade. Он позволяет делать вставки партиалов, использовать inline-javascript, переменные, миксины и ещё много разных крутых штук.
Структура папки src/html
Все партиалы снабжаем префиксом `_` (нижнее подчеркивание), чтобы при сборке мы могли их отфильтровать и игнорировать.
helpers/_variables.jade
Сохраняем необходимые параметры в переменные. Например, если у нас телефон стоит в нескольких местах страницы, то его лучше сохранить в переменную и в шаблонах использовать именно её.
helpers/_mixins.jade
Часто используемые блоки можно обернуть в mixin.
index.jade
Скелет главной страницы.
meta/_head.jade
Содержимое head.
Сборка JavaScript
В качестве модульной системы используем Browserify. C ним мы можем использовать стиль подключения CommonJS модулей непосредственно в браузере. Кроме этого мы теперь можем использовать ES6-синтаксис: Babel преобразует его в ES5 перед тем, как Browserify соберет js. И перед сборкой мы проходимся jsHint для проверки качества кода.
У Browserify есть один минус: если вы пишете библиотеку с внешними зависимостями (например jQuery-плагин), то он не сможет сделать правильную UMD-обертку. В этом случае я заменяю Browserify на конкатенацию и пишу обёртку руками.
На проекте может возникнуть необходимость формировать несколько наборов js/css.
Например вы пишите фронт + админку. Или библиотеку в 2 вариантах: без зависимостей и в формате jQuery-плагина. Эти сборки нужно разделять. Для этого в настройках сборщика мы создаем массив:
js/css cборщики будут искать в папке с js/css исходниками соответствующий end-point файл (`app.js` или `app.styl`). Через этот end-point файл мы управляем всеми зависимостями бандла. Их структуру я покажу чуть ниже.
Перед передачей бандлов сборщику, мы предварительно пропускаем массив через хелпер `bundler`, который формирует объект с настройками.
Структура папки src/js
app.js
Через этот файл мы рулим всеми зависимостями и порядком исполнения js-компонентов. Имя файла должно совпадать с именем бандла.
В таких случаях используем browserify-shim: плагин, который позволяет превращать обычные библиотеки в CommonJS-совместимые модули. Итак, у нас есть jQuery-плагин `maskedinput`, которого нет в npm.
Добавляем в `package.json` преобразование и выставляем настройки для зависимости:
После этого мы можем подключать модуль:
Сборка CSS
В качестве препроцессора используем Stylus. Плюс проходимся по css автопрефиксером, чтобы не прописывать вендорные префиксы руками.
Структура папки src/css
app.styl
Через этот файл мы рулим порядком подключения css-компонентов. Имя файла должно совпадать с именем бандла.
Все остальные таски — картинки, спрайты, очистка и пр. — не требуют дополнительных комментариев (на самом деле я просто устал уже строчить). Исходники лежат в репозитории: github.com/alexfedoseev/js-app-starter
Если есть косяки или дополнения — буду рад обратной связи через комментарии тут или issues / pull requests на Github. Удач!
Практическое руководство по использованию CSS Modules в React приложениях
Привет Хабр! Предлагаю вашему вниманию свободный перевод статьи «Practical Guide to React and CSS Modules» от Tatu Tamminen.
В прошлом веб-разработчики тратили много времени и сил на создание повторно используемых компонентов. Оcобую проблему представлял собой CSS и природа его каскадов. Например, если разработчик создаёт компонент для отображения древовидной структуры, то как он может гарантировать, что CSS класс (например, .leaf), используемый в этом компоненте, не приведёт к побочным эффектам в других частях приложения? Были созданы различные методологии и соглашения, чтобы справиться с проблемами селекторов. БЭМ и SMACSS — широко используемые методологии, которые хорошо выполняют свои задачи, но в то же время далеко не идеальны. В этой статье рассказывается о недостатках таких методологий, основанных на соглашении об именах, о том, что представляют собой CSS Modules, и о том, как эти модули можно использовать в React приложении.
Проблема с каскадами
Давайте создадим повторно используемый компонент select в качестве примера, иллюстрирующего проблемы глобальных стилей. Стилизация элемента напрямую — это плохое решение, поскольку в других местах сайта нам может потребоваться или изначальный нестилизованный элемент, или совсем другая его стилизация. Вместо этого можно использовать синтаксис БЭМ для определения классов:
Если бы новый класс item был создан без префикса select__, то у всей команды могли бы возникнуть проблемы, если бы кто-нибудь захотел использовать такое же имя item. При этом неважно, разработчик ли пишет CSS или же его генерирует какая-то утилита. Использование БЭМ помогает решить эту проблему, вводя контекст для элемента select.
Синтаксис БЭМ является шагом вперёд по направлению к компонентам, так как «Б» в БЭМ расшифровывается как «Блок», а блоки можно интерпретировать как легковесные компоненты. Select — это компонент, у которого есть различные состояния (select—loading) и потомки (select__item).
К несчастью, использование соглашений по именованию и мышление в терминах компонентов не решает всех проблем селекторов. Коллизии имён всё ещё не гарантированы, а семантическая избыточность имён увеличивает риск опечаток и требует дисциплинированной команды, где каждый на все сто процентов понимает соглашения. Опечатки включают в себя использование одного дефиса вместо двух, путаницу между модификатором (—) и блоком (__) и прочее.
CSS Modules спешат на помощь
CSS модуль — это CSS файл, в котором все имена классов и анимаций имеют локальную область видимости по умолчанию.
Ключевая идея здесь — локальная область видимости.
Чтобы проиллюстрировать эту концепцию, давайте создадим JavaScript и CSS файлы компонента.
Это простой пример, который, однако, содержит много всего, происходящего за сценой.
Теперь CSS файл содержит намного меньше шума, чем в БЭМ версии, потому что в нём больше нет префиксов и специальных символов, задающих контекст. Почему же стало возможным удалить префикс .select—, не создавая при этом проблем?
Оператор import в JavaScript файле загружает CSS файл и конвертирует его в объект. В следующем разделе мы рассмотрим, как настроить рабочее окружение, позволяющее импортировать CSS файлы.
Каждое имя класса из CSS файла является свойством объекта. В примере выше это styles.select, styles.icon и т. д.
Если имя свойства — это имя класса, то какое же значение у этого свойства? Это уникальное имя класса, и уникальность обеспечивает то, что стили не «протекают» в другие компоненты. Вот пример хешированного имени класса: _header__1OUvt.
Вы можете подумать: «Какой ужас!» В чём смысл изменения осмысленного имени класса на непонятный хеш? Основная причина в том, что такой идентификатор гарантированно является уникальным в глобальном контексте. Позднее в этом руководстве мы изменим механизм создания идентификаторов, так что они будут иметь более осмысленный вид, но при этом останутся уникальными.
Вот ключевые преимущества использования CSS с локальной областью видимости:
Для простоты в этой статье мы остановимся на сборщике модулей Webpack и библиотеке React.
React, Webpack и CSS Modules
Для быстрого создания приложения можно использовать Create React App.
Следуя инструкциям в документации, мы создадим и запустим новый проект практически мгновенно.
Вуаля, и у нас работающее React приложение:
Начальная страница сообщает нам, что нужно редактировать файл App.js.
Используются ли CSS Modules в Create React App? Это можно узнать, взглянув на файл App.js. CSS файл импортируется, но не присваивается никакой переменной, при этом во всех атрибутах className используются строки вместо динамических значений.
С этой точки зрения Create React App не поддерживает CSS Modules, так что нужно изменить конфигурацию, чтобы включить эту поддержку.
Настройка Create React App для поддержки CSS Modules
Чтобы получить доступ к скрытому конфигу сборки, нужно выполнить команду eject. Внимание: если вы сделали это, то вернуться обратно вы уже не сможете.
Теперь можно открыть папку с конфигами для webpack:
Create React App использует webpack для сборки, поэтому webpack.config.dev.js — тот самый файл, который нужно изменить (а также webpack.config.prod.js для настроек продакшна — прим. переводчика).
Найдём раздел, задающий, что делать с CSS файлами (в оригинальной статье используется старый синтаксис конфигов webpack, здесь же я использовал новый — прим. переводчика):
Когда мы изменим этот раздел, как показано ниже, то это на мгновение разрушит стилизацию сайта, поскольку будет включена поддержка CSS Modules, но требуются ещё изменения в самом компоненте. При изменении конфига webpack, можно изменить правило именования CSS классов, чтобы в них была и читаемая часть, и хеш для обеспечения уникальности:
Что делают эти загрузчики loaders? В файле webpack.config есть закомментированная секция, описывающая загрузчики стилей и CSS:
Опция modules: true в настройках css-loader включает поддержку CSS Modules. Параметр localIdentName изменяет шаблон имени класса таким образом, что оно включает в себя имя компонента React, имя класса и уникальный хеш-идентификатор. Это позволит производить отладку намного легче, потому что легко можно идентифицировать все компоненты.
Использование CSS Modules в React
Можно проверить, что конфигурация работает, добавив вызов console.log после оператора import.
Заменяя import ‘./App.css’; на
мы получаем следующий вывод в консоль браузера:
Сейчас классы уникальны, но они не используются в React компонентах. Нужно сделать ещё два шага, чтобы применить стили к React компонентам. Во-первых, нужно изменить имена классов согласно camelCase нотации. Во-вторых, нужно изменить атрибуты className так, чтобы они использовали импортированные классы.
Использовать camelCase нотацию необязательно, но при доступе к классам из JavaScript легче писать styles.componentName, чем styles[«component-name»].
Исходный файл стилей выглядит так:
Больше нет необходимости в префиксах App, поэтому сейчас хороший момент, чтобы удалить их тоже. Модифицированный CSS будет выглядеть так:
Следующий шаг — изменить использование классов в компоненте. Результат будет следующим:
Теперь наш компонент использует CSS Modules.
Как нарушить границы CSS модуля, когда это необходимо
Подход, описанный в предыдущем разделе, является основным для React проектов, но разработчики обычно быстро обнаруживают, что им нужен способ выделять и использовать общие стили. В этом контексте «общие» значит лишь то, что компонент должен наследовать что-то от базовых стилей.
Эту общую информацию могут представлять собой переменные (цвета, размеры шрифта, и т. д.), хелперы (миксины SASS) или utility-классы.
CSS Modules дают возможность композиции с помощью ключевого слова from. Композиция возможна и между классами из разных файлов.
В следующем примере имеется два файла: один для базовых стилей кнопки и второй для реализации кнопки Submit. Можно сказать, что класс submitButton должен быть представлен через композицию базовых стилей кнопки и некоторых дополнительных свойств.
Если есть необходимость в использовании переменных, то можно использовать или препроцессор, например, SASS или Less, или настроить поддержку переменных в webpack.
Пример из документации webpack по переменным в CSS:
Этот пример можно изменить, используя собственные имена переменных. Это нужно потому, что переопределение стандартных значений, таких как blue, делает CSS файл менее понимаемым, так как больше нельзя быть уверенным, было ли переопределено какое-то значение или нет.
Заключение
В этом руководстве мы начали с рассмотрения проблем глобального CSS, затем увидели, как CSS Modules улучшают ситуацию, вводя область видимости CSS и заставляя нас думать в терминах компонентов. Также мы рассмотрели, как легко можно начать экспериментировать с CSS Modules, используя React Starter Kit.
CSS Modules используются совместно со сборкой всего фронтэнда, то есть, с поддержкой в браузере нет никаких проблем. Браузеры получают обычный CSS от сервера, так что нет никакой возможности «сломать» сайт, используя CSS Modules. Наоборот, при этому мы только повышаем его надёжность, уменьшая количество потенциальных багов. Webpack с загрузчиками, сконфигурированными для поддержки CSS Modules, не создаёт никаких проблем, так что без сомнений можно рекомендовать этот инструмент к использованию.
Если вы использовали CSS Modules в своих проектах, я (то есть, автор оригинальной статьи — прим. переводчика) хотел бы услышать о вашем опыте!
→ Публикация — свободный перевод статьи «Practical Guide to React and CSS Modules». Автор статьи Tatu Tamminen
→ Исходный код можно найти в react-cssmodules-demo
→ Также заслуживает внимания CSS Modules Webpack Demo
Быстрое кроссплатформенное HTML5 приложение на Framework7
Задумываясь о разработке html5 приложения, многим сразу на ум приходит jQuery, или точнее jQueryMobile. И попробовав написать даже самое простенькое приложение используя jQueryMobile, очень легко разочароваться, так как производительность и отзывчивость получившегося html5 приложения куда ниже ожидаемого, и уж совсем его не сравнить с нативными приложениями.
Соответственно, если продолжить идти по пути html5, вы постепенно узнаёте, что тормоза и плохая отзывчивость из-за того, что есть множество тонкостей, например, что jquery далеко не самый быстрый вариант для приложения или по-умолчанию любое нажатие пользователя срабатывает с 300мс задержкой, что ухудшает отзывчивость.
Также важным моментом является есть ли набор готовых типичных компонентов, таких как список, кнопки, боковое меню итд, время на повторную разработку которых нет смысла тратить. Можно добавить еще к этому списку то, что как-то всё таки нужно решить проблему производительности, чтобы конкурировать с нативными приложениями.
Framework7
И мы, наконец, подходим к самому главному, чтобы не забивать себе голову решением таких проблем, а получить сразу готовый инструмент для разработки быстрых, отзывчивых и функциональных html5 приложений, существует Framework7. Сам я с ним столкнулся совершенно случайно, и удивился тому, насколько он прост в использовании без необходимости искать решения в разных местах, достаточно просто подключить framework7.js.
Пример приложения
Чтобы далеко не ходить, создадим небольшое приложение-пример, где можно будет посмотреть, как объединить отдельные компоненты фреймворка в единое приложение. Будем использовать slide menu, pull to refresh, infinite scroll, смену material/ios style на лету и огромным списком на 8000 элементов, который не тормозит (virtual list).
Для начала рассмотрим каркас index.html:
Добавление компонентов очень просто реализовано (для каждого компонента есть инструкция на сайте), например, чтобы добавить pull-to-refresh, достаточно добавить в
класс pull-to-refresh-content, и дизайн стрелочки, которая будет показываться при обновлении:
Теперь надо добавить table view (list view), в котором будет список наших элементов. Для создания коротких списков подойдет List View (Media List итд, список можно создавать статически или динамически):
Но для очень длинных списков требуется выгрузка элементов, которые сейчас не видны на экране, это необходимо для того, чтобы ничего не тормозило, и приложение работало как и нативное. Такий список называется Virtual List, и создается так же просто:
В дальнейшем список надо будет проинициализировать и заполнить в app.js
Сюда же добавим infinite-scroll, который добавляет так же, добавлением одноименного класса, дизайна крутилки и указанием начиная с какого расстояния вызывать infinite-scroll:
Чтобы сменить ios стиль на material стиль и наоборот, добавим 2 кнопки, например, в левом меню:
Позже на класс changestyle повесим обработчик, чтобы реагировал на нажатие и менял css файл на указанный в rel.
Теперь рассмотрим файл app.js, в котором производится настройка приложения, инициализация списков итд.
В итоге получается очень отзывчивое, легкое и быстрое html5 приложение, которое можно использовать как и где угодно.
Ускоряем html5 приложения на старых версия android. Crosswalk
Хоть у нас и получилось очень быстрое и легкое приложение, на старых версиях андроид оно всё равно будет недостаточно производительным.
Дело в том, что на версиях андроид до 4.4 используется очень тормозной webview (убедиться в этом можно, например, если на 4.1 андроид поставить chrome beta и запустить приложение в нём, а потом сравнить с тем, что есть во встроенном браузере, то разница в скорости будет очень заметна). Поэтому, если просто запаковать html5 приложение в apk, оно будет использовать именно встроенный тормозной webview.
Только начиная с 5.x андроида, webview обновляется отдельно и базируется на свежем chromium, благодаря чему html5 приложение будет работать быстро и плавно.
Проще говоря, если нужна хорошая производительность от html5 приложения на любых устройствах и любых версиях андроид, нужно чтобы оно работало на chromium движке. Проект, который позволяет это сделать, называется crosswalk и вместо встроенного webview используется свой собственный, который работает на последней версии chromium.
Самый простой способ проверить как ваше html5 приложение будет работать с использованием crosswalk, это установить Intel XDK, создать пустой «Standart HTML5» проект, и заменить в созданном проекте папку www на вашу.
После этого выбрать Build и нажать на Crosswalk for Android. Приложение будет скомпилировано на удаленном сервере, и спустя несколько минут вы получите ссылку на apk (версия для arm и x86). К минусам можно отнести тот факт, то размер приложения увеличится на
Что такое Tailwind CSS и как внедрить его на сайт или в React-приложение?
Jul 30, 2020 · 10 min read
CSS может стать вашим лучшим другом или злейшим врагом. Несмотря на то, что он невероятно гибкий, а результаты его применения порой кажутся магией, без должного внимания он может выйти из-под контроля, как и любой другой код.
Как же Taiwind CSS помогает в управлении стилями?
Что такое Tailwind?
Tailwind CSS — это “utility-first” (“полезность прежде всего”) CSS-фреймворк, предлагающий обширный каталог классов и инструментов для облегчения стилизации сайта или приложения.
Основная идея состоит в том, что пр и разработке проекта вам не нужно иметь дело с таблицами стилей и беспокоиться о том, как переопределить тот каскад из 10 селекторов, который вот уже 2 года преследует ваше приложение.
Чем Tailwind так хорош?
О преимуществах Tailwind можно рассказывать ещё очень долго, мы же в этом руководстве сосредоточимся на основах. Поехали!
Часть 1: Подключение Tailwind CSS к статичной HTML-странице
Начнём с подключения Tailwind CSS напрямую к статичной HTML-странице. Думаю, что, уделяя основное внимание Tailwind, а не приложению, мы сможем лучше понять, что именно происходит с фреймворком.
Шаг 1: Создание новой страницы
Просто создайте новый HTML-файл. Выбор контента для него остаётся за вами. Я использую для этого fillerama.io, чтобы контент выглядел повеселее.
Чтобы упростить себе задачу, можете воспользоваться моим файлом.
Шаг 2: Подключение Tailwind CSS через CDN
Чтобы получить полнофункциональную версию Tailwind, обычно рекомендуется подключение через npm. Мы же сейчас пока просто пытаемся понять, как он работает, поэтому давайте добавим ссылку на CDN в блок нашего документа.
Первое, что бросается в глаза после сохранения изменений и обновления страницы — все стили сбросились!
Это ожидаемо. У Tailwind есть предустановленные стили для обеспечения кроссбраузерности. Они состоят из популярного normalize.css и надстроек над ним.
Но нам ведь необходимо узнать, как использовать Tailwind вместе с нашими собственными стилями.
Шаг 3: Использование Tailwind CSS для добавления стилей на страницу
Теперь, когда Tailwind установлен, у нас появилась возможность использовать его огромную библиотеку утилитарных классов — с их помощью мы вновь стилизуем страницу.
Давайте начнём с добавления margin ко всем нашим параграфам (
Наименование класса строится по шаблону, который вы увидите и в остальных утилитарных классах: в данном случае m означает margin, применяемый по оси y ( y), со значением 5 (Tailwind использует rem — стало быть, значение равно 5rem).
Вот что здесь происходит:
Теперь займёмся списками. Сначала добавим классы ненумерованному списку (
- ):
Вот что мы сделали:
Вот и всё — мы стилизовали списки.
И наконец настало время сделать наш контент более читабельным — установим ему максимальную ширину и отцентрируем. Для этого к тегу добавим следующее:
Итак, наша страница готова.
Шаг 4: Добавление кнопки и других компонентов
Добавим кнопку в наш статичный пример.
Особенность Tailwind в том, что в нём заведомо нет готовых классов для компонентов: предполагается, что разработчики, скорее всего, будут переопределять их под свои потребности. Это значит, что нам нужно создавать собственные компоненты с помощью утилитарных классов.
Для начала добавим новую кнопку. Вставьте фрагмент кода, показанный ниже, в любое место на странице. Я вставлю его после тега первого параграфа (
Вы можете заметить, что, как и другие элементы, кнопка не стилизована, однако если на неё кликнуть, она среагирует. Давайте зададим кнопке соответствующий внешний вид — добавим следующие классы:
Вот что здесь происходит:
Теперь у нас есть кнопка.
Вы можете применять эту методологию к любому другому компоненту, который захотите создать. И, хотя всё это выполняется вручную, скоро мы выясним, как упростить этот процесс при разработке более динамичных проектов, например тех, что созданы на React.
Часть 2: Подключение Tailwind CSS к React-приложению
Для большей реалистичности подключим Tailwind CSS к приложению, созданному с помощью Create React App.
Для начала давайте рассмотрим этапы, которые вам нужно будет пройти, чтобы подключить Tailwind к вашему проекту с установкой Create React App. Затем мы воспользуемся контентом из последнего примера, чтобы воссоздать его уже на React.
Шаг 1: Создание нового React-приложения
Я не собираюсь слишком подробно останавливаться на этом шаге. Суть в том, что мы запустим новое React-приложение при помощи Create React App.
Перед тем как начать, можете ознакомиться с инструкциями в официальной документации React.
После запуска сервера разработки вы должны увидеть приложение.
Теперь мы можем перенести в него весь наш старый контент. Для этого скопируйте всё содержимое тега из статичного примера и вставьте в обёртку
Заменим все атрибуты class=» из скопированного контента на className=» для соответствия атрибутам React.
И напоследок поменяем className App в обёртке
Сохранив изменения и перезагрузив сервер, вы обнаружите, что страница выглядит хорошо. Но это впечатление обманчиво.
У React есть собственные базовые стили, и, хоть страница и выглядит нормально, мы всё ещё не используем на ней Tailwind. Так давайте же установим его!
Шаг 2: Подключение Tailwind CSS к React-приложению
Чтобы подключить Tailwind к приложению, нужно пройти несколько этапов. Убедитесь, что проходите их все — только так удастся создать нужную конфигурацию.
Для начала добавим зависимости:
Согласно документации Tailwind, нам нужно иметь возможность обрабатывать стили, чтобы они были должным образом добавлены в поток. Поэтому выше мы сделали следующее:
Также добавим две зависимости для разработки, чтобы облегчить себе работу с кодом:
Теперь давайте зададим конфигурацию для postcss. Для этого создайте в корне проекта файл с именем postcss.config.js и скопируйте в него следующее:
Этот код добавит плагины Tailwindcss и Autoprefixer в конфигурацию postcss.
Нам необходимо сделать конфигурацию частью процессов прослушивания и сборки. В файле package.json добавьте следующие два определения к свойству scripts :
Также включите в скрипты start и build команды:
Конфигурация готова. Теперь давайте попробуем вернуть наши стили к тому состоянию, в каком мы оставили их в статичном примере.
Замените всё содержимое файла App.css на следующее:
Этот код импортирует базовые стили, компоненты и утилитарные классы Tailwind, чтобы он работал так, как от него и ожидается.
Теперь самое время вернуться к серверу разработки. Если он уже запущен, перезапустите его, чтобы применились все изменения в конфигурации.
Страница должна выглядеть точно так же, как она выглядела в статичном примере.
