🔍 SVG: что это такое и с чем его едят?

Тег <svg> – это элемент, используемый для описания векторных изображений в формате SVG прямо в HTML-документе. SVG используется для создания графики, которая может масштабироваться без потери качества, поэтому он отлично подходит для использования на различных устройствах и размерах экрана. SVG можно стилизовать и анимировать с помощью CSS и манипулировать с использованием JavaScript, а также этот элемент поддерживает фильтры, маски, клипы и другие сложные эффекты.

Важные атрибуты SVG:

- width и height – задают ширину и высоту изображения.
- viewBox – определяет область просмотра изображения.
- preserveAspectRatio – управляет сохранением пропорций изображения при вписывании в область отображения.
- fill и stroke – задают цвет заливки и цвет контура объектов внутри SVG соответственно.

🤔 Подробнее про viewBox

Атрибут viewBox в SVG задает область просмотра, которая определяет часть SVG, что будет видимой, и масштабирование этой области. Проще говоря, viewBox позволяет вам контролировать отображение SVG без изменения его реальных размеров.

ViewBox принимает четыре значения: min-x, min-y, width, height:
- min-x и min-y указывают на начальную точку видимой области.
- width и height обозначают размеры этой области.

Например, следующий SVG рисует квадрат, левый верхний угол которого находится в точке (10, 10), а правый нижний в (60, 60), так как высота и ширина составляют по 50 пикселей. Элемент <svg> использует viewBox для изменения его масштаба и области просмотра:

<svg width="140" height="140" viewBox="0 0 70 70">
    <rect x="10" y="10" width="50" height="50" fill="red" />
</svg>

⬇️ Пример для визуализации приложен к этому посту. Краткое объяснение:

- viewBox="0 0 70 70" означает, что видимая область начинается в точке (0, 0) с размерами 70x70, и визуально наш квадрат будет находиться в центре с отступами в 10 пикселей от краёв видимой области.
- При этом визуально изображение масштабируется в 2 раза, так как область просмотра в 70x70 пикселей пропорционально увеличена до размера элемента SVG 140x140 пикселей.

⚡Особое CSS-свойство: currentColor

Это специальное свойство в CSS, которое можно использовать в SVG для задания цвета элементов, например в качестве значения fill или stroke. Значение currentColor ссылается на значение свойства color наследуемого элемента. Таким образом, если в примере выше у элемента <rect> указать fill="currentColor", а для всего SVG в css задать { color: red }, то квадрат также останется красным. Это особенно удобно, когда в SVG несколько элементов или когда цвет элементов контролируется извне.

🔗 Узнать подробнее о возможностях SVG можно в этой статье. В ней также описаны варианты элементов, которые могут использоваться внутри тега <svg>.

⚡️Новое видео на канале! Мы продолжаем экспериментировать, и в этот раз в формате подкаста обсудили плюсы, минусы и подводные камни работы в IT https://youtu.be/IWq_LFVA5IQ

🤔 Адаптивный iFrame - правда или миф?

Нередко возникает потребность использовать iFrame - элемент HTML, позволяющий внедрять на одну веб-страницу другую веб-страницу. iFrame действует как окно или портал, через который можно видеть и взаимодействовать с другим документом, не покидая исходной страницы.

Основная проблема iFrame в том, что он не обладает такой гибкостью, как стандартные HTML-элементы. Например, его нельзя просто и безболезненно растянуть на весь родительский контейнер.

❓ Но что делать, если хочется, например, растянуть iFrame по ширине контейнера, при этом сохранив пропорции окна? Современный CSS позволяет это сделать при помощи свойства aspect-ratio. Это свойство полезно не только для iFrame, но и для изображений и вообще любых элементов.

На самом деле, до появления aspect-ratio ситуация c iFrame не была совсем безысходной. Приходилось выкручиваться, добавляя элементу четко рассчитанный padding-top или padding-bottom.

🔗 Рекомендуем прочитать статью, в которой приведены примеры обеих реализаций. А подробнее про aspect-ratio можно узнать на MDN.

💣 Разбираемся с особенностями CSS-свойства z-index

CSS-свойство z-index используется для управления порядком перекрытия элементов вдоль оси z (ось, перпендикулярная экрану). Это свойство определяет, какой из элементов находится "поверх" других, когда они находятся на одном и том же месте в документе или перекрываются.

Как работает z-index:

1. Применение: z-index может быть применён только к элементам, у которых задано свойство position со значением, отличным от static. Например, relative, absolute, fixed или sticky.

2. Числовые значения: Чем выше значение z-index, тем выше "слой", на котором будет находиться элемент. Значения могут быть положительными или отрицательными.

3. Локальная контекстная наложенность: z-index работает в рамках одного контекста наложения. Есть несколько способов задать новый контекст наложения, но об этом мы поговорим немного позже. Здесь важно понимать, что элемент с z-index: 1000 не перекроет элемент с z-index: 5, если они находятся в разных контекстах наложения.

Примеры:

Элемент с бо́льшим значением z-index будет перекрывать элемент с меньшим значением, если они расположены в одном контексте наложения:

<div style="position: relative; z-index: 1;">
    <div style="position: absolute; z-index: 2;">Перекрывает</div>
    <div style="position: absolute; z-index: 1;">Перекрываемый</div>
</div>

Элемент с отрицательным z-index может быть расположен под базовым уровнем своего контекста. Например, через него можно явно указать, что элемент будет фоном внутри своего родителя:

<div style="position: relative">
    <div style="position: absolute; z-index: -1">Содержимое фона</div>
    Основное содержимое блока
</div>

🔗 Подробнее про z-index на MDN.

🔍 Продолжаем разговор про z-index: Контекст наложения

Контекст наложения (stacking context) — это концепция в CSS, которая определяет, как элементы должны перекрываться или как они наложены друг на друга на веб-странице. Контекст наложения создается в следующих случаях:

1️⃣ Корневой элемент (HTML): По умолчанию корневой элемент создает контекст наложения.

2️⃣ Свойства position и z-index: Любой элемент с свойством position отличным от static, и заданным значением z-index задаёт новый контекст наложения.

3️⃣ Некоторые CSS-свойства также создают новый контекст наложения:

🔸 opacity со значением меньше 1.
🔸 transform, не равное none.
🔸 filter, не равное none.
🔸 perspective, большее нуля.
🔸 clip-path, не равное none.
🔸 mask / mask-image / mask-border, не равные none.
🔸 mix-blend-mode, кроме normal.
🔸 will-change, упоминающее любое из свойств, создающих контекст наложения.
🔸 isolation: isolate.

Внутри контекста элементы сортируются сначала по порядку расположения в HTML, а элементы с указанным z-index перемещаются в соответствии с их значениями z-index. Элемент с более высоким z-index находится над элементом с более низким z-index.

Особенностью контекста наложения является его изоляция: z-index работает только в пределах одного контекста наложения и не взаимодействует с элементами, которые находятся за его пределами в других контекстах. Это означает, что z-index одного блока не может влиять на элементы, находящиеся в другом блоке, если каждый из них создает собственный контекст наложения.

<style>
    #content-1 { color: red; height: 18px }
    #new-context { margin-top: -12px }
    #content-2 { color: blue; height: 18px }
    #content-3 { color: green; margin-top: -12px } 
</style>

<div id="main" style="position: relative; z-index: 1;">
    <div id="content-1" style="position: relative; z-index: 10;">#content-1</div>
    <div id="new-context" style="opacity: 0.7;">
        <div id="content-2" style="position: relative; z-index: 200;">#content-2</div>
        <div id="content-3" style="position: relative; z-index: 100;">#content-3</div>
    </div>
</div>

🔹 Здесь элемент #new-context задаёт новый контекст наложения внутри контекста #main.
🔹 Поэтому, несмотря на то, что z-index у элементов #content-2 и #content-3 выше, чем у #content-1, они визуально будут расположены ниже, так как #content-1 поднимается выше всего #new-context благодаря своему z-index.
🔹 При этом #content-2 будет перекрывать #content-3 внутри общего контекста наложения #new-context.

🔗 Подробнее про контекст наложения на MDN.

⚡ Новое видео на канале: наглядно показываем, как работает z-index и контекст наложения, чтобы развеять все вопросы! https://www.youtube.com/watch?v=6p86YhPLwsY

🚀 Разбираемся с видами зависимостей в package.json

Зависимости в проекте Node.js — это модули или пакеты, которые ваше приложение использует для корректной работы. Эти зависимости указываются и управляются через package.json - файл, который служит своего рода картой или спецификацией для проекта. Сегодня разберемся, какие у проекта могут быть зависимости и как правильно их использовать.

1️⃣ dependencies — это основные зависимости, которые необходимы вашему приложению в продакшене. Они включают библиотеки и фреймворки, от которых напрямую зависит работоспособность вашего проекта. Например:

"dependencies": {
  "express": "^4.17.1",
  "mongoose": "^5.9.10"
}

2️⃣ devDependencies — это инструменты и библиотеки, используемые во время разработки и тестирования, но не нужные в продакшене. В эту категорию входят компиляторы, тестовые фреймворки и другие инструменты для улучшения процесса разработки. Пример:

"devDependencies": {
  "eslint": "^7.2.0",
  "jest": "^26.0.1"
}

3️⃣ peerDependencies — обычно используются при разработке библиотек или плагинов. Они указывают на зависимости, которые должны быть установлены в проекте, который будет использовать вашу библиотеку. Но при этом не устанавливают их автоматически, оставляя это на усмотрение разработчика, чтобы не вызывать дублирование библиотек с разными версиями. Например, если ваша библиотека требует обязательного наличия React 18-й версии, то нужно указать:

"peerDependencies": {
  "react": "18.x"
}

Как и для чего разделять зависимости?
- Чистота: Разделение помогает уменьшить размер сборки продукта.
- Безопасность и скорость: В продакшне загружаются только необходимые библиотеки.
- Совместимость: PeerDependencies предотвращают конфликты версий, особенно важно для разработчиков библиотек.

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

🪄 Разбираемся в семантическом версионировании: как управлять зависимостями в npm без хаоса

Семантическое версионирование, или SemVer, является популярной системой версионирования в мире программирования, особенно в экосистеме Node.js и npm. Эта методология активно применяется для управления версиями пакетов и модулей, чтобы облегчить управление зависимостями и минимизировать риски, связанные с обновлениями. Разберём основные составляющие семантического версионирования:

1️⃣ Основной номер версии (Major version) – увеличивается, если сделаны изменения, ломающие обратную совместимость.
2️⃣ Минорный номер версии (Minor version) – увеличивается, когда добавляются новые возможности, не ломающие существующий функционал.
3️⃣ Патч-версия (Patch version) – увеличивается при внесении исправлений ошибок, которые не затрагивают интерфейсы и не добавляют новых функциональностей.

👉 Пример версии по SemVer: 2.3.1, где 2 – основной номер, 3 – минорный, 1 – патч.

В package.json версии зависимостей можно обозначать следующими способами:

🔹 Точная версия: Указание конкретной версии, например, "react": "18.2.0". Это гарантирует, что будет использована именно эта версия.

🔹 Звездочка (*) или x: Означает использование любой версии в пределах указанной мажорной версии. Например: "react": "18.x"

🔹 Знак тильда (~): Использование тильды, например, "eslint": "~7.2.0", позволяет установить последнюю патч-версию для указанного минорного изменения. Это означает, что будут использованы все последующие патчи к версии 7.2.

🔹 Знак каретки (^): Каретка, например, "webpack": "^4.0.0", позволяет обновляться до последней минорной версии в рамках мажорной версии 4. Так, npm сможет установить любую версию от 4.0.0 до 5.0.0 не включительно.

🔹 Оператор сравнения (>=): Определяет минимально допустимую версию. Например, если указано "lodash": ">=4.17.0" , npm будет устанавливать версию lodash не ниже 4.17.0. Это означает, что при наличии более новых версий, подходящих под эту спецификацию, они будут установлены. Но с этим способом стоит быть осторожнее, так как могут выйти новые мажорные версии, сильно ломающие обратную совместимость.

🔹 Git-репозитории и теги: Можно указать зависимость от конкретного git-commit'a или тега, например, "a-library": "github:myusername/a-library#v1.0.0".

Использование этих подходов позволяет контролировать версии зависимостей в проекте, минимизируя риски поломок из-за неожиданных изменений в используемых библиотеках и модулях. SemVer и npm предоставляют разработчикам гибкие инструменты для управления зависимостями в их проектах.

🔗 Подробнее о семанитическом версионировании можно прочитать в официальной документации. А в этой статье подробно описано использование SemVer в npm.

Про попапы ходит невероятное количество споров, но иногда это действительно страшная вещь!

📢 Новые хуки в React 19! Часть 1.

В одном из предыдущих постов мы писали про обновление React 19, и вы проголосовали за новые хуки для работы с состоянием! 💡

Я решила поразбираться в них, чтобы понять, что к чему и чем они отличаются от наших старых добрых и любимых useState и useReducer. На разборе у меня были три самых свежих и интересных:

1. useActionState
2. useFormStatus
3. useOptimistic

Все примеры лежат в нашем репозитории здесь 👉 GitHub

🔍 useActionState и useFormStatus

В документации React говорится, что useActionState даст преимущество в работе с Server Actions, поэтому я подняла проект, используя Next 15, который из коробки поддерживает React 19 (и сам находится в бете).

Без использования директивы "use server", useActionState может показаться ничем не отличающимся от useState. Однако в сочетании с Server Action он становится очень интересным инструментом.

В самом первом примере есть простая форма с одним полем, которая отправляет данные на сервер с помощью useActionState.

export function FormUseActionState() {
  const [result, formAction] = useActionState(submitForm, null);

  return (
    <form action={formAction}>
      <h2>Form With useActionState</h2>
      <input name="title" />

      <button type="submit">Save!</button>
    </form>
  );
}

'use server';

export const submitForm = (prevState: string | null, form: FormData) => {
  return form.get('title')?.toString() || '';
};

Примечательно, что в случае работы с Server Action нам достаточно просто передать его первым аргументом в useActionState, и дальше мы можем использовать возвращаемый из хука formAction напрямую в теге form. Таким образом мы:
1. совершенно не думаем о том, каким образом данные будут ходить с клиента на сервер и обратно
2. полагаемся на нативную браузерную обработку форм, не используя дополнительные обработчики onChange каждого поля и отдельные состояния, если нам это не нужно
3. можем миксовать серверный и клиентский код рядом друг с другом

Во втором примере можно увидеть, что у нас также доступен isPending:

const [result, formAction, isPending] = useActionState(submitForm, null);

Однако если у нас произойдет какая-то ошибка в серверном submitForm, то все наше приложение упадет - можно посмотреть на 3 примере. А это значит, что мы обязательно должны позаботиться об обработке ошибок в той функции, которую передаём хуку useActionState.

Также, если мы не хотим заниматься глубоким прокидыванием isPending в дочерние компоненты форм, можно использовать новый хук useFormStatus - 4 пример

const { pending } = useFormStatus();

✍️ Во второй части разберем хук useOptimistic, а пока пишите в комментариях, что показалось интересным и как, по вашему мнению, часто будут использоваться новые хуки!

❤️ Реагируйте, если хотите увидеть обзор на Server Components и Server Actions!