Единицы измерения viewport в CSS. Все 24 комбинации.

Раньше в CSS было всего четыре единицы измерения, которые вам нужно было знать, и они могли охватить практически все мыслимые варианты использования. Однако со временем и изменением технологий этих четырех единиц уже не хватало для обработки всех вариантов использования. Из-за этого CSS добавил еще 20 единиц измерения области просмотра. Это много, но они разбиты на шесть основных с тремя уникальными модификаторами, что дает нам в общей сложности 24 комбинации.

Оригинальные четыре единицы измерения

Основными единицами CSS являются vw, vh, vmin и vmax. Скорее всего, вы использовали или видели их раньше, поэтому рассмотрим их кратко.

vw

vw расшифровывается как Viewport Width и представляет собой процент от ширины окна просмотра. Число, помещенное перед vw, представляет собой процент от ширины области просмотра, которой будет эта длина. Например, если вы написали 10vw, то это будет представлять 10% от ширины вашего окна просмотра. Окно просмотра (viewport) — это по сути размер вашего экрана, поэтому, если бы вы были на большом рабочем столе шириной 1920 пикселей, 10vw означало бы 192 пикселя. Если бы вы вместо этого использовали мобильный телефон шириной 300 пикселей, то 10vw был бы только 30 пикселей.

vh

vh расшифровывается как Viewport Height. Он точно такой же, как vw но для высоты, а не ширины. Эти две единицы можно использовать в комбинации, чтобы легко заставить элемент заполнять весь размер экрана.

.full-screen {
  width: 100vw;
  height: 100vh;
}

vmin и vmax

vmin и vmax представляют собой максимальное и минимальное измерение области просмотра. Например, если вы работаете на телефоне шириной 300 пикселей и высотой 800 пикселей, vmin будет представлять ширину области просмотра, а vmax — высоту устройства. Эти единицы действительно полезны, если вам нужно определить размер элемента на основе наименьшего/наибольшего размера экрана. Например, следующий CSS создаст квадрат, который будет максимально большим, не переполняясь ни в каком направлении, поскольку он никогда не будет больше 100% от наименьшего размера экрана.

.no-overflow {
  width: 100vmin;
  height: 100vmin;
}

Две новых единицы

CSS пытается отойти от строгой модели верха/низа, слева/справа, высоты/ширины к более динамичной модели начала/конца, блочной/инлайн модели. Основная причина этого изменения заключается в том, чтобы упростить внедрение различных направлений написания в коде. Если все ваше приложение переключается с горизонтального направления письма на вертикальное, идея верха/низа или ширины/высоты не обязательно означает одно и то же, поскольку, если вы хотите добавить отступы выше и ниже текста, это будет представлено как отступы слева и справа в вертикальной системе, а не заполнение сверху и снизу. Вот почему CSS добавил модули просмотра vi и vb.

vi

vi расшифровывается как Viewport Inline и представляет собой встроенное (инлайн) направление вашего документа. В горизонтальном направлении это соответствует ширине окна просмотра, а в вертикальном направлении это соответствует высоте окна просмотра. Самый простой способ запомнить направление встроенного текста — помнить, что это то же направление, в котором движется ваш текст. Еще один способ запомнить это: если у вас есть два встроенных элемента (например, два span) рядом друг с другом, направление, в котором они складываются, является вашим встроенным направлением.

.horizontal {
  writing-mode: horizontal-tb;
  width: 10vi; /* То же, что и 10vw */
}

.vertical {
  writing-mode: vertical-lr;
  height: 10vi; /* То же, что и 10vh */
}

vb

vb расшифровывается как Viewport Block и представляет собой направление блока вашего документа. Это противоположно vi, поэтому в горизонтальном направлении это будет соответствовать высоте окна просмотра, а в вертикальном документе это будет представлять ширину вашего окна просмотра. Если вы изо всех сил пытаетесь запомнить эту единицу, просто помните, что направление блока всегда будет направлением, в котором блочные элементы (например, два div) будут складываться друг на друга.

.horizontal {
  writing-mode: horizontal-tb;
  width: 10vb; /* То же, что и 10vh */
}

.vertical {
  writing-mode: vertical-lr;
  height: 10vb; /* То же, что и 10vw */
}

Модификаторы единиц измерения вьюпорта

До сих пор мы рассмотрели шесть основных типов модулей области просмотра, но есть три различных модификатора, которые вы можете добавить к единицам, чтобы они вели себя по-разному, когда ваше окно просмотра может изменять размеры. Например, когда вы просматриваете веб-страницы на мобильном телефоне, вы можете заметить, что адресная строка исчезает при прокрутке вниз. Когда это происходит, ваше окно просмотра технически меняет размер, так как теперь строка URL-адреса больше не занимает часть вашего окна просмотра. Текущие блоки CSS не имеют возможности справиться с этим изменением размера области просмотра, поэтому были добавлены эти модификаторы. Этими модификаторами являются s, l и d. Для того, чтобы использовать модификатор, вам просто нужно разместить модификатор после номера и перед единицей измерения, например 10svw. Это дает нам 4 комбинации для каждого из 6 модулей области просмотра. vw, svw, lvw и dvw. До сих пор все, что мы рассмотрели в этой статье, не использовало модификатор. Если вы не используете модификатор на устройстве, например 10vw или 10vh, браузер автоматически по умолчанию использует один из 3 модификаторов в зависимости от реализации браузера.

Модификатор s

Модификатор s расшифровывается как Small и представляет собой минимально возможное окно просмотра. В нашем примере с мобильным телефоном это будет размер окна просмотра при отображении строки URL. Если вы установите для элемента значение 100svh он будет занимать 100% высоты экрана в зависимости от размера экрана при отображении строки URL. Неважно, видна ли строка URL-адреса или нет, размер этого устройства всегда будет основываться на том, каким будет окно просмотра, если будет отображаться строка URL-адреса.

Модификатор l

Модификатор l расшифровывается как Large и представляет собой максимально возможное окно просмотра. Это в значительной степени противоположно модификатору s. В нашем примере с мобильным телефоном это будет размер окна просмотра, когда строка URL-адреса НЕ отображается. Если вы установите для элемента значение 100lvh, он будет занимать 100% высоты экрана в зависимости от размера экрана, когда строка URL-адреса НЕ отображается. Неважно, видна ли строка URL-адреса или нет, это устройство всегда будет основывать свой размер на том, каким будет окно просмотра, если строка URL-адреса НЕ отображается. Это означает, что если вы установите элемент на 100lvh, а строка URL-адреса показывается, то технически он будет больше, чем экран.

Модификатор d

Модификатор d расшифровывается как Dynamic и представляет текущий размер области просмотра. Это похоже на комбинацию модификаторов s и l. В нашем примере с мобильным телефоном это всегда будет размер текущего окна просмотра, независимо от того, отображается ли строка URL-адреса или нет. Если наша строка URL-адреса отображается, то модификатор d имеет тот же размер, что и модификатор s, а если строка URL-адреса НЕ отображается, модификатор d имеет тот же размер, что и модификатор l. Во время перехода между отображаемой и скрытой строкой URL-адреса это устройство будет динамически увеличиваться в размерах, поэтому оно всегда будет заполнять все доступное пространство. Это здорово, если вам нужно гарантировать, что размер элемента всегда зависит от области просмотра, но может быть обременительным, поскольку это вызовет много перерисовок, поскольку размер постоянно меняется.

Поддержка браузеров

С каждой интересной функцией CSS вы всегда должны учитывать поддержку браузера, и, к сожалению, поддержка браузера для этих новых модулей просмотра не очень хороша. В настоящее время эти новые единицы поддерживают >85% и на самом деле поддерживаются только в Safari и Firefox. Причина такого отсутствия поддержки заключается в том, что это предложение все еще находится на стадии рабочего проекта, что означает, что оно находится на очень ранней стадии своего жизненного цикла и довольно далеко от того, чтобы быть официальным CSS.

Итоги

Хотя 24 юнита могут показаться много, на самом деле это всего лишь шесть юнитов с тремя модификаторами, которые относительно просты. Эти простые комбинации, однако, дают нам большие возможности в построении идеального макета CSS.

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

Что такое tree shaking?

Проще говоря, tree shaking означает удаление недостижимого кода (также известного как мертвый код) из пакета. В переводе tree shaking переводится как встряхивание дерева. Почему? Проведем аналогию. Можно представить свое приложение в виде дерева. Исходный код и библиотеки, которые вы фактически используете, представляют собой зеленые, живые листья дерева. Мертвый код представляет собой коричневые мертвые листья дерева, которые появляются осенью. Чтобы избавиться от опавших листьев, нужно встряхнуть дерево, чтобы они опали.

Этот термин был впервые популяризирован в сообществе фронтенд разработчиков команды Rollup. Но авторы всех динамических языков боролись с этой проблемой гораздо раньше. Идея алгоритма встряхивания дерева восходит как минимум к началу 1990-х годов. В области JavaScript tree shaking стал возможным со времен спецификации ECMAScript модулей (ESM) в ES2015, известной как ES6. С тех пор tree shaking была включена по умолчанию в большинстве сборщиков, потому что они уменьшают размер результирующего кода без изменения поведения программы. Основная причина этого заключается в том, что ESM являются статическими по своей природе. Давайте разберем, что это значит.

ES модули и CommonJS

CommonJS предшествует спецификации ESM. Он появился на несколько лет раньше. Он появился чтобы решить проблему отсутствия поддержки переиспользуемых модулей в экосистеме JavaScript. В CommonJS есть функция require(), которая извлекает внешний модуль на основе предоставленного пути и добавляет его в область видимости во время выполнения. Функция require является такой же функцией, как и любая другая функция. Это делает ее достаточно сложной для оценки результата вызова во время компиляции. Кроме того, возможно добавление вызовов require в любом месте кода — в вызове другой функции, в операторах if/else, в операторах switch и т. д.

В результате широкого внедрения CommonJS архитектуры, спецификация ESM остановилась на новой архитектуре, в которой модули импортируются и экспортируются с помощью соответствующих ключевых слов import и export. Поэтому больше никаких вызовов функций для добавления модулей. ESM также разрешает только объявления верхнего уровня, их вложение в какую-либо другую структуру невозможно. Это и делает его статичным. ESM не зависят от запуска во время выполнения.

Область применения и побочные эффекты

Есть еще одно препятствие, которое нужно преодолеть, чтобы избежать раздувания кода: побочные эффекты (сайд эффекты, side effects). Считается, что функция имеет побочные эффекты, когда она изменяет или зависит от факторов, внешних по отношению к области выполнения. Функция с побочными эффектами считается нечистой (impure function). Чистая функция (pure function) всегда будет давать один и тот же результат при каждом запуске, независимо от контекста или среды, в которой она была запущена.

const pure = (a: number, b: number): number => a + b
const impure = (c: number): number => window.foo.number + c

Сборщики стараются максимально оценить предоставленный код, чтобы определить, является ли модуль чистым. Но оценка кода во время компиляции или во время связывания может зайти слишком далеко. Поэтому предполагается, что пакеты с побочными эффектами не могут быть должным образом устранены, даже если они полностью недоступны. Из-за этого сборщики принимают ключ внутри файла package.json модуля, который позволяет разработчику заявить, не имеет ли модуль побочных эффектов. Таким образом, разработчик может отказаться от оценки кода и сказать сборщику, что код в конкретном пакете может быть исключен, если нет доступного импорта или оператора require, связывающего его. Это не только делает пакет более компактным, но также может ускорить время компиляции.

{
    "name": "some-package",
    "sideEffects": false
}

Если вы разработчик пакета, осторожно используйте побочные эффекты перед публикацией и, конечно же, пересматривайте его при каждом релизе, чтобы избежать каких-либо неожиданных критических изменений.

В дополнение к полю sideEffects также можно указать чистоту для каждого файла, добавляя встроенный комментарий /*@__PURE__*/ к вызову метода.

const x = */@__PURE__*/eliminated_if_not_called()

Эта встроенная аннотацию полезна для разработчика-потребителя. Она полезна в случае, если пакет не объявил sideEffects: false или в случае, если библиотека действительно представляет побочный эффект для определенного метода.

Оптимизация Webpack

Начиная с версии 4, Webpack требует все меньше конфигураций, используя при этом лучшие практики. Несколько плагинов было включено в ядро. Если вы не большой эксперт в webpack или если ваше приложение не содержит специфических сценариев, то tree shaking зависимостей — это вопрос всего одной строки. Файл webpack.config.js имеет корневое поле с именем mode. Всякий раз, когда значение этого свойства production, оно полностью оптимизирует ваши модули. Помимо устранения мертвого кода с помощью TerserPlugin, mode: production присвоит хэшированные имена для модулей и чанков, а также активирует следующие плагины:

• flag dependency usage
• flag included chunks
• module concatenation
• no emit on errors.

Не случайно все это происходит именно в production режиме. Вы не захотите, чтобы ваши зависимости были полностью оптимизированы в режиме разработки, потому что это значительно усложнит отладку. Поэтому я бы предложил использовать один из двух подходов. Для указания режима можно передать флаг режима в интерфейс командной строки Webpack:

# это значение перезапишет значение указанное в webpack.config.js
webpack --mode=production

Либо можно использовать переменную среды process.env.NODE_ENV в webpack.config.js:

mode: process.env.NODE_ENV === 'production' ? 'production' : development

В этом случае вы должны не забыть передать --NODE_ENV=production при развертывании приложения. Оба подхода являются абстракцией поверх известного плагина definePlugin из Webpack 3 и ниже. Какой вариант вы выберете, абсолютно не имеет значения.

Webpack 3 и ниже

Стоит отметить, что сценарии и примеры в разделе “Webpack 3 и ниже” могут не применяться к последним версиям Webpack и другим сборщикам. В этом разделе рассматривается использование UglifyJS 2 вместо Terser. UglifyJS — это пакет, из которого появился Terser, поэтому оценка кода между ними может различаться. Поскольку Webpack 3 и ниже не поддерживает свойство sideEffects в package.json, все пакеты должны быть полностью оценены, прежде чем код будет удален. Уже одно это делает подход менее эффективным, но также необходимо учитывать несколько предостережений.

Как упоминалось выше, компилятор не может сам определить, когда пакет входит в глобальную область. Но это не единственная ситуация, в которой он пропускает tree shaking. Есть более неочевидные сценарии. Рассмотрим пример пакета из документации Webpack:

// transform.js

import * as mylib from 'mylib';

export const someVar = mylib.transform({
  // ...
});

export const someOtherVar = mylib.transform({
  // ...
});

А это его использование:

// index.js

import { someVar } from './transforms.js';

// Use `someVar`...

Невозможно определить, вызывает ли mylib.transform побочные эффекты. Таким образом, никакой код не будет удален. Вот другие ситуации с аналогичным исходом:

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

Инструмент, который может помочь компилятору заставить tree shaking работать, называется babel-plugin-transform-imports. Он разделит все элементы и именованные экспорты на экспорты по умолчанию, что позволит оценивать модули по отдельности.

// до трансформации
import { Row, Grid as MyGrid } from 'react-bootstrap';
import { merge } from 'lodash';

// после трансформации
import Row from 'react-bootstrap/lib/Row';
import MyGrid from 'react-bootstrap/lib/Grid';
import merge from 'lodash/merge';

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

Поднятие (hoisting) и время компиляции

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

(function (modulesMap, entry) {
  // provided CommonJS runtime
})({
  "index.js": function (require, module, exports) {
     let { foo } = require('./foo.js')
     foo.doStuff()
  },
  "foo.js": function(require, module, exports) {
     module.exports.foo = {
       doStuff: () => { console.log('I am foo') }
     }
  }
}, "index.js")

Помимо того, что это трудно анализировать статически, это принципиально несовместимо с ESM, потому что мы видели, что мы не можем обернуть операторы импорта и экспорта. Итак, сейчас сборщики поднимают каждый модуль на верхний уровень.

// moduleA.js
let $moduleA$export$doStuff = () => ({
  doStuff: () => {}
})

// index.js
$moduleA$export$doStuff()

Этот подход полностью совместим с ESM; кроме того, это позволяет оценке кода легко обнаруживать модули, которые не вызываются, и удалять их. Недостаток этого подхода заключается в том, что во время компиляции требуется значительно больше времени, потому что он касается каждого оператора и сохраняет пакет в памяти во время процесса. Это важная причина, по которой производительность пакетов стала еще более серьезной проблемой и почему скомпилированные языки используются в инструментах для веб-разработки. Например, esbuild — это сборщик, написанный на Go, а SWC — это компилятор TypeScript, написанный на Rust, который интегрируется со Spark, сборщиком, также написанным на Rust.

Избегайте преждевременной транспиляции

Есть одна проблема, которая, к сожалению, довольно распространена и может иметь негативные последствия для tree shaking. Короче говоря, это происходит, когда вы работаете со специальными загрузчиками, интегрируя разные компиляторы в свой сборщик. Распространенными комбинациями являются TypeScript, Babel и Webpack — во всех возможных сочетаниях. И у Babel, и у TypeScript есть собственные компиляторы, и соответствующие загрузчики позволяют разработчику использовать их для упрощения интеграции. И в этом кроется скрытая угроза.

Эти компиляторы достигают вашего кода до оптимизации кода. И по умолчанию или из-за неправильной настройки эти компиляторы часто выводят модули CommonJS вместо ESM. Как упоминалось в предыдущем разделе, модули CommonJS являются динамическими и, следовательно, не могут быть должным образом оценены для устранения мертвого кода. Этот сценарий становится все более распространенным в настоящее время с ростом «изоморфных» приложений (т. е. приложений, которые выполняют один и тот же код как на стороне сервера, так и на стороне клиента). Поэтому обязательно проверяйте код, который получает алгоритм оптимизации.

Tree shaking чеклист

Теперь, когда вы знаете все тонкости того как создаются бандлы и работает tree shaking, давайте выведем чеклист. Надеюсь, это сэкономит вам время и позволит оптимизировать не только производительность вашего кода, но, возможно, даже время сборки.

• Используйте ESM, и не только в своей собственной кодовой базе, но также отдавайте предпочтение пакетам, которые сами выдают ESM.
• Убедитесь, что вы точно знаете, какие из ваших зависимостей (если таковые имеются) не объявили sideEffects или не установили их в true.
• Используйте встроенную аннотацию для объявления вызовов методов, которые являются чистыми при использовании пакетов с побочными эффектами.
• Если вы выводите модули CommonJS, обязательно оптимизируйте свой пакет, прежде чем преобразовывать операторы импорта и экспорта.

Создание пакетов

Надеюсь, к этому моменту мы все согласимся с тем, что ESM был хорошей идеей в экосистеме JavaScript. К счастью, авторы пакетов могут принять надежные меры, чтобы облегчить своим пользователям быструю и беспрепятственную миграцию. С некоторыми небольшими дополнениями в package.json ваш пакет сможет сообщить сборщикам, какие среды поддерживает ваш пакет:

• Включите экспорт ESM.
• Добавьте "type": "module"
• Укажите точку входа "module": "./path/entry.js"

И вот пример, который получается, когда соблюдаются все лучшие практики и вы хотите поддерживать как веб-среду, так и среду Node.js:

{
    // ...
    "main": "./index-cjs.js",
    "module": "./index-esm.js",
    "exports": {
        "require": "./index-cjs.js",
        "import": "./index-esm.js"
    }
    // ...
}

В дополнение к этому команда Skypack ввела показатель качества пакета в качестве эталона, чтобы определить, настроен ли данный пакет на долговечность и использует ли лучшие практики. @skypack/package-check может быть добавлен как devDependency в ваш пакет, чтобы легко выполнять проверки перед каждым релизом. Также рекомендую прочитать статью Создание tree-shaking библиотеки с Rollup и Vue, в ней также рассказано почему Webpack не подходит для создания tree-shaked библиотек.