джаваскрипт король
Css сильно развился за последние несколько лет. Препроцессоры становятся основой проектов, и из-за этого такие инструменты сборки, как Grunt и Gulp, становятся обычным явлением. Другой популярной тенденцией в архитектуре внешнего интерфейса является написание стилей css с использованием различных модульных шаблонов, таких как bem, oocss и smacss. Все эти шаблоны делают все возможное, чтобы гарантировать, что каждую таблицу стилей легко поддерживать и что, кроме некоторых общих глобальных стилей, каждый компонент или подкомпонент на странице имеет определенные стили, которые его определяют.
Обычно все эти стили содержатся в одном большом файле или в нескольких разных файлах для оптимизации скорости. Затем javascript будет упакован в аналогичный формат одного или нескольких файлов в зависимости от типа сайта/приложения, которое вы создаете. Это, однако, находится на пороге серьезных изменений в нашей отрасли.
Добро пожаловать в 2015 год, когда люди пишут стили в своем javascript, генерируют css с помощью javascript, пишут разметку в своем javascript и, кажется, сходят с ума. По крайней мере, для меня все это казалось безумием, если не безумием, когда я впервые услышал об этом. Я подумал: «Что это вообще было и почему мы пытаемся написать один язык на другом?» Прежде чем я пойду дальше, я хочу сначала сказать, что они могут быть на что-то.
изменить свое мышление
Давайте сначала поговорим об одном из упомянутых мною ранее моментов: написание разметки в вашем Javascript. Для меня разметка — это священное место, где живет html. Время от времени возникают ситуации, которые заставляют вас писать встроенные теги и стили скрипта (как встроенные, так и теги). Тем не менее, они являются частью спецификации, и хотя они не очень красивы, они по-прежнему полностью действительны.
Когда я впервые увидел файл JSX, я сразу же отключился от него. Javascript не место для написания всей вашей разметки. Пересмотрев его позже, я начал с этим мириться. Я видел большую цель. Эта идея заключается в том, что нам больше не нужно, чтобы Javascript сканировал DOM на наличие элементов, а затем каталогизировал обновления и синхронизировал все. Вместо этого наш Javascript содержит разметку, данные, состояние, откровенно говоря, все. Только пользовательский ввод синхронизируется с нами. Такие фреймворки, как React, позволяют нам это, создавая виртуальный DOM, который проверяет изменения в нашем коде и обновляет реальный DOM только при необходимости. Однако этот сдвиг в мышлении — не единственное изменение.
Еще одним важным изменением в мышлении является концепция написания css в вашем Javascript. Теперь есть два разных вкуса этого, с одним я сталкиваюсь, а с другим, без обид, я просто не согласен. Во-первых, начну с того, с чем не согласен.
мышление внутри коробки
Итак, сначала я хочу сказать, что, хотя я не обязательно согласен с этим подходом, я ценю все мысли и тяжелую работу, которые были потрачены на создание и итерацию этой концепции. Все самые важные функции Интернета пришли от людей, использующих старые концепции и мысли. Все, что сказано, я просто не вижу. Возможно, позже я передумаю, но сейчас это кажется нецелесообразным.
Основная идея заключается в том, что с большими приложениями и сайтами специфичность CSS становится проблемой, а также управление огромным количеством стилей. Не волнуйтесь, встроенные стили здесь, чтобы спасти положение.
Они обеспечивают высокую степень специфичности и привязываются непосредственно к элементам, что обеспечивает (особенно в React) отличный способ быстро отображать изменения состояния, не покидая кодовой базы Javascript.
Я надеюсь, что есть кусок пирога, который я еще не понял, но сейчас у меня есть пара проблем с ним. Во-первых, одно из преимуществ BEM и ему подобных заключается в том, что они предлагают возможность использовать компоненты пространства имен и устранять проблемы специфичности, которые ранее существовали с глобальными стилями. С такими вещами, как модификаторы, они дают вам место для хранения всех стилей для ваших изменений состояния. Кроме того, поскольку это css, у вас есть доступ к псевдоэлементам и состояниям, таким как :before и :focus.
Мне трудно понять, как эти же вещи выполняются в Javascript. Для псевдоэлементов и состояний вы должны либо прослушивать события Javascript, такие как наведение курсора мыши, либо вам нужно вводить теги стиля с каким-то идентификатором для этого компонента для целей специфичности, ни один из которых не звучит как хорошая реализация или что-то лучше, чем css. Опять же, я мог неправильно понять идею, и, честно говоря, хотел бы, чтобы мне рассказали, как она решает эти проблемы. На данный момент, однако, я думаю, что есть только одна реальная интеграция css, которую Javascript имеет в своем наборе инструментов, которая, кажется, действительно связывает вещи воедино.
будьте готовы упаковать его
Как я упоминал ранее, различные инструменты сборки становятся все более популярными. Есть ваши более ранние инструменты сборки, такие как Grunt и более поздний Gulp, но я хочу сосредоточиться, в частности, на Webpack. Теперь я хотел бы сначала сказать, что, вероятно, есть другие инструменты сборки, которые решают ту же проблему, и если они такие фантастические. Тем не менее, я хочу особо упомянуть Webpack, поскольку я видел, как сообщество начало делать с ним что-то удивительное.
Во-первых, для него доступны различные загрузочные библиотеки. Основная идея Webpack состоит в том, чтобы использовать node.js для превращения обычных методов require() в мощный импорт кода, который позволяет использовать все типы файлов: Javascript, изображения, таблицы стилей и, возможно, множество других, о существовании которых я не знаю. Для этого конкретного случая я хочу выделить модуль загрузчика css.
Он позволяет запрашивать (или импортировать) файлы css на уровне компонентов в вашем Javascript, которые затем объединяются вместе. Это позволяет автору проекта иметь автономные компоненты с различными типами ресурсов (js, css и т. д.) и связывать их все в одном файле. Это означает, что если вы просто больше не используете определенный компонент (или, возможно, на этой конкретной странице/экране), то он не будет включен в пакет.
Этот метод также имеет свою долю проблем, которые необходимо решить. Что вы делаете с переменными и примесями (в этом примере я буду ссылаться на sass как на пример предварительно скомпилированного css)? Где вы храните глобальные стили, необходимые для каждой страницы?
На эти вопросы на удивление легко ответить. У них просто есть ответы, которые требуют немного другого угла мышления. Чтобы решить проблему переменных и примесей, вы можете просто убедиться, что каждый новый файл sass имеет правильный импорт в эти файлы, или даже, возможно, создать шаблонный файл компонента, в котором есть все необходимые ресурсы, который используется для импорта одной строки для каждый новый файл компонента sass. Я включил пример ниже:
Что касается проблемы с глобальными стилями и вендорными файлами (бутстрап и т.д.), вам просто нужно добавить импорт в основные js-файлы в вашем проекте, которые загружаются везде, таким образом, они всегда будут включены в ваш бандл.
И последнее, но не менее важное: такие инструменты, как Webpack, позволяют выполнять горячую загрузку файлов Javascript. Проще говоря, он автоматически перезагружает методы файлов, которые сохраняются, аналогично тому, как перезагрузка в реальном времени работает с css. Так же, как автоматическая перезагрузка в css, это быстро повышает вашу производительность, позволяя вам очень быстро перебирать пользовательский интерфейс.
Честно говоря, сначала я не был в восторге от всех этих изменений, но теперь я вижу огромный потенциал в этих достижениях, которые внедряются прямо сейчас. Больше всего на свете я хотел написать это, чтобы просветить тех, кто не знал, и продолжить уже широко распространенный разговор о том, что происходит. И последнее напоминание: эти изменения в мышлении немалые, и к ним нужно привыкнуть. Не позволяйте этому нежеланию удерживать вас хотя бы от экспериментов с тем, что может быть в будущем.
Инструменты/Ресурсы:
