Новости Фронтэнда

Краткая история CSS-in-JS: где мы и куда движемся

Неопубликованный, отчет о текущей истории CSS-in-JS

 

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

Javascript или CSS

Это был Hakon Wium Ли , который первым предложил концепцию каскадных таблиц стилей во время работы в CERN в октябре 1994 года CSS позже был формализован Ли в своей докторской диссертации в Университете Осло 2006 года.

На конференции после лекции о формате CSS. Лекция, представленная 16 февраля 2006 года — за день до его защиты диссертации — неожиданно пророческий бит назад и вперед:

Этан Мунсон: Но я действительно думаю, что вы определили основную проблему,
которая, как бы вы ни предложили, займет некоторое время, чтобы попасть в
любой браузер. Я имею в виду, вы можете это предложить, и если вы действительно хотите,
чтобы это был стандарт, Opera, возможно, будет работать с моментом, когда
стандарт  будет одобрен, но другие производители браузеров, вероятно,
не будут, и пока у вас почти все браузеры не будут запускать что-то — он
не работает.

HWL: Правильно. Существует альтернатива, которая будет работать сегодня, и
это нужно, чтобы извлечь вещи в библиотеки Javascript, в которых у вас были хорошо
написанные библиотеки Javascript, на которые вы могли бы ссылаться, сегодня вы будете
работать даже с IE6. Опять вам придется держать нос, некоторые
из нас должны были бы держаться за нос, чтобы это произошло, но это
можно сделать легче. Я думаю, что нам действительно нужно
преследовать оба эти пути. Я думаю, нам нужно будет больше в CSS,
но не задерживайте дыхание, чтобы оно использовалось.

Этан Мунсон: Что, если бы вы могли сделать переход более плавным? Что, если бы
вы могли, это был бы уродливый код, но что, если бы вы могли добавить
функции в CSS, которые хотите, но сделать путь, с помощью которого кто-то может
использовать Javascript, реализованный парсер, чтобы определить наличие этого
кода в CSS и может поддерживать это с библиотекой Javascript?

— Таблицы стилей и проблемы, связанные с динамическими аспектами
Интернета

Как мы все знаем , CSS пошел дальше , чтобы стать методом для определения того, каким должен быть стиль веб — документ. Он был достаточно силен, чтобы удовлетворить потребности веб-разработчиков, работающих над всеми типами проектов, и был достаточно доступен для того, чтобы возиться с любителями веб-разработчиков, чтобы работать без гигантской кривой обучения.

CSS также обеспечил приятное и аккуратное решение проблем для каждой части того, что стало святой троицей веб-документов: HTML, Javascript и CSS. HTML обработанный контент структурирования, поведение, предоставляемое JavaScript, и CSS продиктовали, как все выглядело.

Эта установка обеспечила отличное, проверенное сражения решение для публикации веб-страниц в течение многих лет. Он был надежным, имел низкий барьер для входа и сделал доступным веб-разработку. Все было правильно во всемирной паутине.

 

Продвижение в JavaScript, однако, внедрило совершенно новую экосистему разработки с течением времени. К 2011 году рост рамок JavaScript для создания приложений с одной страницей стал влиять на ландшафт разработки. AngularJS появился в октябре 2010 года , EmberJS в декабре 2011 года , ReactJS в марте 2013 года , VueJS в феврале 2014 года .

В период с 2011 по 2014 год ландшафт разработки смещался от веб-документов-сайтов, которые в основном являются статическим контентом, и продолжил работу в сфере Single Page Apps, поскольку популярность этих фреймворков росла. По мере того, как СПА созрели по своей сложности и поведению, пользователи стали ожидать, что сайты будут иметь все более динамичный, богатый возможностями.

В ноябре 2014 года инженер Facebook Кристофер Чедо, а также Вье , рассказал о концепции, которую он назвал CSS-in-JS . Он открыл разговор с тем, что стало довольно известным слайдом, изложив то, что он видел как основные проблемы с CSS, которые необходимо преодолеть, чтобы разработчики могли спокойно поддерживать высокодинамичные веб-приложения, особенно в масштабе:

 

С 2014 года многие разработчики работали над реализацией CSS-in-JS. Обработка CSS с использованием JavaScript предоставляет уникальное решение этих проблем. Если вы хотите более глубокое погружение в текущие реализации, а также за и против использования CSS-in-JS-методов, я очень рекомендую статью Indrek Lasn « Все, что вам нужно знать о CSS-in-JS» .

Использование Javascript для применения и управления CSS с первого взгляда, по-видимому, нарушает принцип « Разделение проблем» . В превосходной работе Криштиану Растелли « Пусть наступит мир на CSS» ( статья / видео ) он предлагает, чтобы CSS-in-JS поддерживал разделение проблем в такте. Мы просто должны нарезать наши проблемы по-разному. Подумайте, разделились ли проблемы по линиям элементов вместо технологических линий. Мы все еще находимся в чистоте:

Разделения проблем с другой точки зрения

Документ против веб-приложений

«Любой, кто работал с CSS достаточно долго, должен был примириться с его агрессивным глобальным характером — модель, четко разработанная в эпоху документов, в настоящее время изо всех сил пытающаяся предложить разумную рабочую среду для современных современных веб-приложений». [ Конец Глобальный CSS ]

В Интернете примерно два типа веб-сайтов: те, которые состоят в основном из статического контента (документов) и тех, которые в основном интерактивны (веб-приложения). В Mark Далглейш «s Конец глобальной CSS он утверждает , что спецификация CSS, который является прямым потомком спецификации , которая была создана и ратифицированной в конце 90 -х лет не адекватно удовлетворить потребности современных веб — приложений.

Построение сайта «Документ» и создание веб-приложения каждый имеет свои собственные потребности. Если традиционный (не CSS-in-JS) CSS соответствует потребностям вашего проекта, продолжайте! Действительно, даже если вы создаете веб-приложение, в защиту традиционного CSS над CSS-in-JS есть несколько продуманных аргументов .

Каждый проект имеет особые потребности, и каждый разработчик имеет уникальные предпочтения. Тогда вопрос не должен быть «будет ли CSS-in-JS или традиционный CSS выигрывать войн CSS?», А скорее «какое решение CSS соответствует потребностям моего проекта»?

Я считаю, что заключительные заявления Криштиану Растелли « Пусть будет мир на CSS», это лучше, чем все, что я читал:

Я не могу влиять на такое сообщество, как наше. Но я могу попытаться убедить вас, что есть лучший способ, чем сражаться друг с другом.

Итак, вот мои предложения:

  1. Охватить постоянно меняющийся характер Интернета.
  2. Будьте осторожны с вашими словами: они могут повредить.
  3. Будьте прагматичны, не догматичны. Но больше всего, быть любопытным.

Если мы сможем охватить постоянно меняющийся характер Интернета, мы сможем легче найти сопереживание для наших коллег-разработчиков.  Оценивая прагматизм по поводу догмы, мы можем держать открытый взгляд на новые понятия. Будучи любопытным, мы можем обнаружить новые вещи, которыми стоит поделиться, одновременно развивая и  наш набор инструментов.

 

 

 


 

Начало работы с TDD и Vue.js

 

Зачастую начинается самая сложная часть использования тестовой разработки или TDD. Вам нужно загружать пакеты со странными зависимостями, получить свой тестовый набор, работающий с вашей системой сборки, а затем вам нужно выяснить, как написать тест! Неудивительно, что так много разработчиков начинают убегать, когда вы его начинаете.

Но вы не обычный разработчик. Вы готовы начать использовать TDD с Vue, чтобы быть уверенным, что ваш код работает точно так, как предполагалось. Вместе мы получим тесты, работающие в новом проекте Vue, пройдем тесты по умолчанию, а затем добавим некоторые из наших собственных.

Настройка

Самый простой способ начать работать с TDD — использовать инструмент vue-cli . Если вы еще не использовали его, инструмент vue-cli выдает новый проект Vue для вас из командной строки.

Когда вы используете vue-cli для создания проекта, все, что вам нужно сделать, это следовать подсказкам, а затем тесты будут автоматически настроены для вас. Как легко это? Давайте рассмотрим процесс, чтобы мы могли точно видеть, как это сделать.

Первым шагом является установка инструмента vue-cli, если вы еще этого не сделали. Используя NPM, вы можете открыть свой терминал и запустить его, npm install -g vue-cliчтобы установить его.

Прежде чем мы создадим наш проект, нам нужно выбрать шаблон. Вю-кли дает нам несколько различных вариантов шаблонов , таких как WebPack , browserify , PWA и простой . У каждого из них есть свои уникальные настройки, и я оставлю это вам, чтобы выбрать тот, который вам подходит. Обратите внимание, что «простые» версии не включают тестирование. Для этого урока я собираюсь использовать шаблон webpack.

Теперь перейдите в каталог, в котором вы хотите создать свой новый проект Vue. Здесь вы можете запустить vue init <template-name> <project-name>проект для вашего проекта. Инструмент vue-cli теперь предложит вам ряд вопросов о вашем проекте, например:

Как вы можете видеть, я принял большинство настроек по умолчанию, но я отключил vue-router, потому что нам это не понадобится. То, что вы выбираете, зависит от вас, но убедитесь, что вы включили модульные тесты!

Когда вы включаете модульные тесты, вам будет предложено выбрать тестировщика.

Я выбрал Карму и Мокку, потому что это то, с чем я знаком. Но я слышал о Джесте, и я определенно хочу попробовать это в ближайшее время.

После этого vue-cli спросит вас, хотите ли вы настроить сквозное тестирование с помощью Nightwatch. Это немного выходит за рамки этого учебника «Начало работы», поэтому мы пока не будем говорить «нет». Наконец, выберите, хотите ли вы запускать vue-cli npmили yarnпосле установки, и он будет генерировать проект для вас.

Bada bing bada, у нас есть новый проект Vue с уже установленными нами испытаниями! Если вы cdвключите свой проект и запустите его npm run test, мы увидим, что vue-cli включает в себя некоторые тесты для нас и их передачу.

Взгляд вокруг

Теперь, когда мы все настроены, давайте посмотрим вокруг и посмотрим, как выглядит наш проект. Наша файловая структура должна выглядеть так:

Мы видим, что vue-cli много работали для нас! Хотя здесь много чего, для этого урока мы заботимся только о каталогах testи srcкаталогах.

Внутри srcмы видим, что у нас есть два компонента Vue и main.jsфайл. Затем, внутри test, мы можем увидеть некоторые файлы, настроенные на тестирование, и наш specsкаталог. Здесь мы будем писать наши тесты. Давайте заглянем внутрь HelloWorld.spec.jsи посмотрим, что у нас есть.

Давайте разложим этот файл по частям. Наверху мы импортируем Vue и наш компонент HelloWorld, чтобы мы могли использовать их в тесте. Затем у нас есть наша describe()функция, которая инкапсулирует наше утверждение тестирования. Наше утверждение определено в it()функции. Здесь мы можем увидеть тест для нашего компонента.

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

Прыгая назад HelloWorld.spec.js, мы знаем, что наш «субъект» есть HelloWorld.vueи что наш тестовый вопрос should render correct contents. Итак, как мы отвечаем на это?

Во-первых, мы используем Vue.extend(HelloWorld)для создания подкласса базового конструктора Vue с параметрами HelloWorld. Затем мы создаем HelloWorld, чтобы мы могли взаимодействовать с ним. При тестировании это обычно называют настройкой или «построением мира». По сути, мы инициализируем нашу среду, чтобы соответствовать соответствующему состоянию, с которым мы хотим взаимодействовать во время теста.

Наконец, мы готовы рассмотреть наше утверждение. Здесь мы ожидаем, что текст внутри .hello h1равный «Добро пожаловать в ваше приложение Vue.js». Это правда? Ну, если вы уже прошли тесты, вы знаете, что они проходят. Итак, давайте посмотрим, HelloWorld.vueкак настроить код.

В строке 3 мы видим, что h1внутри .helloпроисходит рендеринг a msgиз наших данных Vue. Затем в строке 28 мы видим, что msgэто строка, которую мы ожидали: «Добро пожаловать в ваше приложение Vue.js». Похоже, наши тесты были правильными!

Написание теста

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

Существует много разных стратегий. Я считаю, что хорошая практика заключается в том, чтобы подумать о том, что должен делать данный компонент, а затем написать тест, чтобы проверить его. Обычно я не беспокоюсь о «единичном» тестировании каждого метода или свойства. Вместо этого я сосредоточен на тестировании поведения, которое я ожидаю от компонента.

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

Для начала давайте подумаем о нашем тесте на секунду. Мы хотим убедиться, что все ссылки отображаются правильно. Итак, давайте напишем тест, чтобы убедиться, что мы показываем правильное количество ссылок.

Вернемся HelloWorld.spec.js, прямо под нашим первым it(), мы можем добавить еще один такой вот:

it(‘should show all the links’, () => {    })

Теперь нам нужно создать наш мир, как мы это сделали в нашем первом тесте. Итак, мы можем добавить те же самые consts, что и в первом.

it(‘should show all the links’, () => {    const Constructor = Vue.extend(HelloWorld)    const vm = new Constructor().$mount()})

Мы хотим, чтобы все ссылки находились на странице нашей заявки. Попробуем найти счет всех ссылок, которые отображает наш компонент, и посмотреть, соответствует ли это тому, что мы ожидали. Внутри HelloWorld.vueнас есть 9 ссылок, поэтому мы ожидаем, что наш компонент будет отображать 9 ссылок.

it(‘should show all the links’, () => {   const Constructor = Vue.extend(HelloWorld)   const vm = new Constructor().$mount()   expect(vm.$el.querySelectorAll(‘a’).length)   .to.equal(9)})

Когда мы запускаем наш тестовый пакет, мы можем видеть, что мы становимся зелеными! Для проверки работоспособности попробуйте прокомментировать ссылку, чтобы убедиться, что она терпит неудачу, как мы ожидали.

Заключение

В этом пошаговом руководстве мы многое рассмотрели. Мы начали с разработки нашего проекта с vue-cli. Затем мы рассмотрели тесты по умолчанию, чтобы посмотреть, как они работают. Наконец, мы написали собственный тест, чтобы убедиться, что наш компонент будет работать так, как мы ожидали.

Хотя мы много покрывали, это всего лишь верхушка айсберга тестирования. Чтобы продолжить изучение тестирования Vue, я рекомендую вам проверить курс Jeffery Way Testing Vue на Laracasts. Некоторые другие полезные ресурсы — Руководство по началу работы Mocha и Vue.js для тестирования .

Конечно, мы все знаем, что лучший способ учиться — продолжать практиковать. Итак, для вашего следующего проекта или нового компонента попробуйте настроить тесты и сделать снимок. Бьюсь об заклад, вы поразите себя тем, чего вы можете добиться. Если вы застряли, не стесняйтесь задавать мне какие-либо вопросы в Twitter . И до следующего раза, счастливое кодирование!