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

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

1 — заголовок, 2 — описание, 3 — изображение, 4 — кнопки

Текст основного заголовка обозначается тегом h1, его стилизацией мы и займёмся.

Полезные подсказкиВыбирайте правильные цвета

Если работаете с брендбуком, сосредоточьтесь на фирменных цветах. Если инструкций нет, сначала подберите сочетающиеся цвета, потом приступайте к оформлению.

Делайте заголовок уникальным

Тест и стиль должны быть уникальными. На одной веб-странице нужен только один тег h1 — это ради SEO и производительности, особенно если у заголовка сложный стиль.

Выбирайте правильные шрифты

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

CSS градиенты цвета текста

Градиент — цветовой переход между цветами, при котором они смешиваются. Есть три способа добавить цветовые градиенты к тексту заголовка CSS:

1. linear-gradient()

2. radial-gradient()

3. conic-gradient()

1. linear-gradient()

Функция обеспечивает переход цвета по прямой линии. Сделаем для старта заголовок в HTML:

Используйте семантический тег header, как показано, тег section с ID или проверенный с class=»header». Главное, чтобы заголовок был заметным и узнаваемым.

Функция linear-gradient() позволяет добавлять специфические параметры, в том числе направление градиента и как минимум два значения цвета. Но можно добавлять больше — количество цветов не ограничено. Посмотрим на CSS:

header h1 {
  font-size: 70px;
  font-weight: 600;
  background-image: linear-gradient(to left, #553c9a, #b393d3);
  color: transparent;
  background-clip: text;
  -webkit-background-clip: text;
}

Свойство background-clip гарантирует, что фон не выйдет за пределы элемента — в данном случае это текста. Свойство color установлено как transparent, так что фон видно прямо за заголовком. Результат кода: светлый цвет перетекает в тёмный слева направо:

Линейный градиент текста слева направо

Стилизовать заголовок с градиентом можно в других направлениях:

Линейные градиенты текста с разными направлениями

Градиент может быть и диагональным:

linear-gradient(to bottom left, #553c9a, #ee4b2b);

Направление можно указать с помощью углов:

linear-gradient(45deg, #553c9a, #ee4b2b);Линейный градиент по диагонали

Начало перехода цвета можно задать, добавив процентное значение после первого цвета. Фиолетовый занимает 45% текста заголовка, а потом переходит в красный:

linear-gradient(to right, #553c9a 45%, #ee4b2b)Линейный градиент с процентами2. radial-gradient()

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

background-image: radial-gradient(#553c9a, #ee4b2b);

Указать направление с помощью radial-gradient() нельзя, но зато можно указать форму: круг или эллипс.

radial-gradient(circle, #553c9a, #ee4b2b);

radial-gradient(ellipse, #553c9a, #ee4b2b);Радиальный градиент

Для изменения положения градиента есть четыре параметра:

1. closest-side

2. closest-corner

3. farthest-side

4. farthest-corner

3. conic-gradient()

Этот градиент тоже начинается с исходной точки. Вокруг неё вращается цветовой переход. Для наглядности добавим к заголовку третий цвет.

background-image: conic-gradient(#553c9a, #ee4b2b, #00c2cb);

Результат:

Пример конического градиента

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

conic-gradient(#553c9a, #ee4b2b, #00c2cb, #553c9a);

После цветов можно добавить процентные значения, чтобы контролировать точки начала цветовых переходов.

conic-gradient(#553c9a 30%, #ee4b2b 40%, #ee4b2b 70%, #00c2cb 80%, #553c9a);

Итог:

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

conic-gradient(
    #553c9a 0%, #553c9a 33%, #ee4b2b 33%, #ee4b2b 66%, #00c2cb 66%, #00c2cb 99%
  );

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

Бонус: повторяющиеся градиенты

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

repeating-linear-gradient(to right, #553c9a, #ee4b2b 10%, #553c9a 20%);

repeating-radial-gradient(circle closest-corner at 100px 100px, #553c9a, #ee4b2b 10%, #553c9a 20%);

repeating-conic-gradient(#553c9a 0%, #553c9a 10%, #ee4b2b 10%, #ee4b2b 20%, 

#00c2cb 20%, #00c2cb 30%);

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

Используйте оттенки одного цвета

Чтобы получить паттерн repeating-radial, используем такой синтаксис:

repeating-radial-gradient(circle closest-corner at 100px 100px, #553c9a, #ee4b2b 10%, #553c9a 20%);

Теперь поменяем красный на светло-фиолетовый:

repeating-radial-gradient(circle closest-corner at 100px 100px, #553c9a, #b393d3 10%, #553c9a 20%);

Итог:

Используйте не только оттенки одного цвета. Жёлтый хорошо сочетается с оранжевым,  а зелёный — с синим.

Используйте правильные параметры

Помните четыре параметра для radial-gradient? Посмотрим ещё.

repeating-radial-gradient( ,, , );

Градиенту можно задать форму circle или ellipse. По умолчанию это ellipse с положением в центре.

Размер фигуры можно определить с помощью параметров:

1. closest-side — форму градиента определяет ближайшая к центру стороной элемента;

2. closest-corner — форму градиента определяет ближайший угол элемента;

3. farthest-side —форму градиента определяет сторона элемента, удалённая от центра;

4. farthest-corner — форму градиента определяет удалённый от центра угол.

Далее идёт позиция от corner или side. Это может быть процентное значение или длина.

Используйте минимум два цвета, но помните, что повторение первого в качестве третьего даёт плавный переход. Для ясности используем красный и фиолетовый:

Вот что получится при repeating-radial-gradient использовании значений closest-:

А теперь при использовании значений farthest-:

Между двумя первыми заголовками нет большой разницы, потому что градиент расходится из центра наружу. Тот же результат можем получить, используя linear-gradient. Лучше указать форму и определить точки цветовых переходов.

Видно, что свойство repeating-radial-gradient со значением closest-side или closest-corner выглядит ярче, но снижает читаемость, если использовать неподходящие цвета. Значения farthest-corner или farthest-side позволяют получить чёткий текст даже с контрастными цветами. 

Дайджест новостей из мира фронтенд-разработки за последнюю неделю 23–29 мая.

К сожалению, на хабре нельзя устанавливать alt для картинок, поэтому …ДоступностьHTMLCSSJavaScriptReactNode.jsAngularVueИнструментыОбщее

Как выделяться с помощью типографики. Рассматривайте возможности типографики как дополнительную возможность привлечь внимание вашего интерфейса.

Оптимальная длина строки. Спойлер: 50-75 символов. Меньше 50 или больше 75 может ухудшить читабельность

Почему в вебе закругляют углы?

Как читать статьи на английском языке

В дайджесте много статей и видео на английском языке, чтобы это не стало препятствием: в Google Chrome есть функция перевода страницы с любого популярного языка, а видео можно перевести в Яндекс Браузере.

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

Виды шрифтов для сайта

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

• С засечками (в их названии часто присутствует serif) – они хорошо подходят для печатных изданий, а для сайта не совсем логично их использовать, так как они не всегда удобны к восприятию и рассеивают внимание посетителя. Поэтому такие шрифты востребованы для заголовков, подзаголовков и выделения отдельных блоков;

• Рубленые или без засечек (обозначаются как sans serif) – нейтральные и универсальные шрифты, которые удобны к прочтению и восприятию. Многие сайты оформляются только при помощи таких шрифтов;

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

Наиболее востребованные шрифты для сайтов

Количество популярных бесплатных css на просторах Интернета достаточно большое, равно как и количество шрифтов, которые доступны для бесплатного скачивания. Найти жирный (bold) шрифт не составляет труда, но необходимо знать о самых популярных шрифтах, использование которых практически всегда оправдано. Среди таких шрифтов (они все могут быть кириллическими рукописными) можно выделить:

• Roboto – наиболее популярный шрифт, имеющий громадное количество вариаций, среди которых можно найти жирный (bold), light, black;

• Open Sans – наиболее удобочитаемый всего читать, поэтому в Интернете его можно встретить почти на каждой интернет-странице;

• Montserrat – простой, интересный и привлкательный для чтения, но при этом позволяющий «зацепиться» взгляду во время просмотра больших документов;

• Roboto Condensed – имеет особенность – он узкий и несколько вытянутый, но при этом понятный и читабельный;

• Source Sans Pro – имеет максимальный набор начертаний, причем разработан Adobe, поэтому отлично подойдет для Фотошопа и других графических приложений. Скачать кириллицу для него можно во всех вариантах;

• Oswald – чаще всего применяется для заголовков, как для полноценных сайтов, так и для приложений;

• Merriweather – имеет засечки и немного вытянутые и плавные буквы. При желании можно скачать вариант и без засечек;

• Noto Sans – отличается упрощенным дизайном символов, но при этом очень хорошо читаем, благодаря чему отлично походит для текстовых материалов;

• Yanone Kaffeesatz – имеет стиль типографской печати кофеен начала 20-го века. Немного старомоден, но выглядит дорого, благодаря чему отлично подходит для заголовков рекламного характера;

• Caveat – имеет элегантные прописные литеры, которые узнать довольно просто. Хорошо подойдет для заголовков, но для текста.

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

Особенности выбора шрифтов для сайта

Интересно то, что по статистике пользователи перед тем, как прочитать текстовые блоки на сайте, бегло просматривает заголовки, после чего принимают решение о дальнейшем прочтении, поэтому важно уделить особое внимание выбору шрифтов и их сочетанию. Использование традиционных шрифтов – Open Sans, Roboto, Montserrat – это беспроигрышный вариант, так как они простые, читабельные, привычные. Поэтому важно учесть то, какой контент необходимо оформить.

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

• Не стоит применять более трех шрифтов на странице, иначе текст никто не будет читать. Если необходимо выделить отдельные фрагменты, то имеет смысл использовать один и тот же шрифт, но в разных начертаниях;

• Читабельность на первом месте – шрифт должен быть, прежде всего, читабельным, иначе страница будет только просматриваться и закрываться;

• Шрифтовые пары должны сочетаться между собой. Если шрифты плохо сочетаются между собой, то стоит один из них сразу же менять;

• Логичность обязательна – цвета букв должны быть подобраны с учетом фона, а размер быть таким, чтобы его было удобно читать.

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

Эта статья — перевод оригинальной статьи Thomas Belin «Get to know your browser’s performance profiler»

Также я веду телеграм канал “Frontend по-флотски”, где рассказываю про интересные вещи из мира разработки интерфейсов.

Вступление

В какой-то момент своей карьеры вы, возможно, просматривали вкладку «Производительность» в инструментах разработки вашего любимого браузера. В конце концов вы попытались создать profile, но, вероятно, быстро разочаровались. Высокая плотность отображаемой информации делает ее немного подавляющей и несколько пугающей. Я был там, я понимаю тебя!

Хорошая новость: кривая обучения на самом деле не такая крутая!

Как только вы усвоите несколько концепций, он внезапно станет вашим самым ценным инструментом для устранения узких мест в производительности.

Эта статья даст вам несколько ключей к пониманию того, как работает профайлер и как правильно его использовать.

Давайте полностью забудем о console.log и console.time, сегодня мы погрузимся в профилировщик производительности!

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

Модель данных

Первым шагом, который я предпринял, чтобы понять, как работает профилировщик, было чтение документации Mozilla об их новом профилировщике производительности (это отличный документ, прочтите его).

Первый вау-эффект, который у меня был, был, когда я увидел модель данных, которую использовал профайлер. Это на самом деле довольно просто

В документации Mozilla модель данных представлена следующим образом:

A A A
| | |
v v v
B B B
|
v
C

A, B и C — имена функций, а по оси X мы получаем время. По умолчанию профилировщик Firefox и Chrome настроен на создание снимка каждые 1 мс, что означает, что здесь каждый столбец представляет 1 мс.

В этом примере это означает, что стек со временем развивался таким образом.

• в 0мс A вызывал B, а B все еще работал;

• в 1 мс B вызывал C, а C все еще работал;

• в 2 мс C закончил свою работу, и мы вернулись в B;

• в 3 мс стек оказался пуст.

Из этого профилировщик может сделать следующие выводы:

• А почти сразу вызвал B;

• Мы пробыли ~1 мс в B, прежде чем вызвать C;

• C потребовалось ~ 1 мс для выполнения;

• B снова потребовалось еще ~ 1 мс после вызова C;

• А закончил выполнение сразу после вызова B.

Имея в виду эту модель, мы можем создать некоторые данные:

A A A A A A A A A
| | | | | | | | |
V V V V V V V V V
B B B B B B B B B
|
V
C

B занимает немного времени до и после вызова C. Мы потратили ~1 мс на C и не потратили время на A:

A A A A A A A A A
| |
V V
B B
|
V
C

A занимает некоторое время перед вызовом B. B и C занимают ~1 мс.

Ограничения этой модели

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

Представим следующий сценарий:

function A() {
B(); // < takes 0.5ms // snapshot #1 C(); // < takes 0.4ms D(); // < takes 0.2ms // snapshot #2 E(); // < takes 0.5ms }

Сгенерированный профиль, скорее всего, будет выглядеть примерно так:

A A
| |
v v
B D

В этом профиле не будет упоминаний о C или E.

Но мы здесь для отладки долгих задач, помните? Нет необходимости разбирать эти быстро выполняющиеся функции. Нам до них нет дела!

Собственное время (self time) против общего времени (total time)

Одно немного запутанное понятие в профилировщике — это собственное и общее время.
Однако на самом деле это понятие довольно легко понять.

Их можно определить так:

• собственное — время, проведенное в самой функции;

• общее — время, проведенное в функции и всех дочерних функциях, которые она вызывает.

Чтобы прочувствовать это, вот конкретный пример:

function superExpensive() {
for (let i = 0; i < 1e10; i++) { console.log(i); } } function main() { superExpensiveComputation(); // < takes 1000ms for (let i = 0; i < 1e6; i++) { // ^ takes 5ms console.log(i); } }

main будет иметь собственное время 5мс, но общее время 1005мс. superExpensiveComputation будет иметь общее и собственное время 1000мс

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

Погружение в UI

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

Здесь я сосредоточусь на профилировщике Firefox, но те же принципы применимы и к профилировщику Chrome.

Определение долгих функций верхнего уровня: дерево вызовов

Для начала возьмем очень простой пример кода. Представьте, что где-то есть кнопка, и при нажатии на нее мы запускаем функцию calculateNumber.

function generateNumber(nbIterations) {
let number = 0;
for (let i = 0; i < nbIterations; i++) { number += Math.random(); } return number; } function computeNumber() { console.log(generateNumber(1e9)); }

Вот что мы получим в нашем отчете профилировщика:

• Поскольку профилировщик фактически профилирует все процессы Firefox, мы хотим убедиться, что мы просто проверяем текущее веб-приложение, над которым работаем.

• Мы здесь веб-разработчики, нам не нужны внутренние трассировки стека браузера, давайте оставим только трассировки стека JS.

• Мы ясно видим, что больше всего времени мы тратим на функцию generateNumber (здесь функция появилась в 488 выборках, что означает, что она выполнялась как минимум 488мс).

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

Определение долгих вложенных функций: инвертирование стека вызовов

Теперь рассмотрим следующее:

function computeMultipleNumbers() {
let number = 0;
for (let i = 0; i < 10; i++) { const fnName = `gen${Math.round(Math.random() * 100)}`; // We create a function with a random name const fn = new Function(`function ${fnName}() { return generateNumber(1e7); } return ${fnName}`); number += fn()(); } result.innerText = number; }

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

Посмотрим, как выглядит результат:

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

Теперь, если мы инвертируем стек.

Тут становится понятно, где мы собственно потратили время: в функции generateNumber 🙂

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

Это дерево вызовов:

topLevel // self 0
first // self 0
second // self 0
third // self 10
fourth // self 7
fifth // self 8

Это инверсия стека вызовов:

third //self 10
second
topLevel
fifth // self 8
fourth
second
topLevel
fourth // self 7
second
topLevel

Таким образом, мы можем быстро определить, что мы потратили ~ 10мс на вызов third из topLevel > second

Заключение

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

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

Мы не рассмотрели здесь, что такое Flame Graph или Stack Chart, как профилировать асинхронный код или продвинутые методы, такие как маркеры. Это то, что я хотел бы осветить в следующей статье.

Все мы знаем про, или слышали про практики и паттерны проектирования SOLID, GRASP, MVC, MV** и даже применяем их с переменным успехом, стараясь нащупать эффективный подход к построению приложений. Но это лишь приводит к разнообразию реализаций наших приложений и частей функционала.

И поэтому я уже долгое время пытаюсь понять по каким правилам должно строиться фронтенд приложение чтобы оно удовлетворяло следующим критериям:

• легкое расширение функционала приложения;

• безболезненное внесение изменений в существующий функционал;

• унифицированная структура приложения;

• быстрый onboarding новых разработчиков на проект;

• понятный и прозрачный код;

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

Какие у нас есть варианты?

«Организация файловой структуры это все что нам нужно»

Каждый лид или сеньор сами для себя выбирают варианты компоновки структуры приложения и выделения сущностей приложения. По итогу каждая система становится уникальной и неповторимой. И для того, чтобы разобраться в ней, нужны время и усилия, которые нужно будет тратить каждый раз при смене проекта. Плюс никто не отменял «бас фактор».

Существует большое кол-во статей, описывающих «оптимальные», по мению авторов, варианты таких подходов. Пример.

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

Domain Driven Design

Много умных дядек, таких как Мартин Фаулер и дядюшка Боб, написали много статей про него. На бэкенде в больших и сложных проектах он неплохо себя зарекомендовал. Но есть и много изъянов: туча абстракций, для простых действий нужно писать много кода, ну и разобраться, как готовить DDD та еще задача. 

Есть примеры как готовить это на фронте, но, как видно, проблемы никуда не уходят и кол-во абстракций удручают. Простой onboarding тут невозможен, без прочтения «The Big Blue Book» и пары недель общения с ментором.

Есть переосмысленные подходы к архитектуре, которые больше похожи на правду и наверняка могут где-то успешно применены. 

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

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

Джимми Богарт в своей статье пишет что DDD подход не совершенен и избыточен, и, как следствие, он предлагает переработанный подход vertical slices. И это отличный подход, о котором стоит почитать отдельно. Эта идея довольно простая и мы можем адаптировать ее к фронтенд приложениям. 

Если DDD не удалось применить для наших нужд, то можно попробовать построить его на более общих правилах, которые предоставляет нам «Clear architecture», ведь DDD основывается именно на них.

Clear architecture

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

Разработчики Flutter тоже столкнулись с проблемой сложности переиспользования логики между различными представлениями, и предложили подход — Business Logic Component (BLoC). Он позволяет снизить нагрузку на компоненты пользовательского интерфейса, отделив от них бизнес-логику.

Тут пример одной из реализаций BLoC в React.

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

FCD — Feature Sliced Design

И недавно для меня стало открытием методология FCD — Feature Sliced Design. На мой взгляд лучшем решением будет обратить внимание именно на эту методологию. 

Ссылка на офф сайт.

Методология не привязана к конкретному стеку технологий и применима к большинству frontend-приложений. Документация содержит примеры реализации на JavaScript + React, но FSD успешно адаптируется и к другим комбинациям инструментов.

Для проектирования архитектуры методология предлагает следующие архитектурные абстракциями на основе которых строиться наше приложение.

Ниже приведу описание терминов из документации:Layers​

Первый уровень абстрагирования — согласно скоупу влияния.

• app — инициализация приложения (init, styles, providers, …);

• processes — бизнес-процессы приложения управляющие страницами (payment, auth, …);

• pages — страницы приложения (user-page, …);

• features — части функциональности приложения (auth-by-oauth, …);

• entities — бизнес-сущности (viewer, order, …);

• shared — переиспользуемый инфраструктурный код (UIKit, libs, API, …).

Slices​

Второй уровень абстрагирования — согласно бизнес-домену.

Правила, по которым код разделяется на слайсы, зависят от конкретного проекта и его бизнес-правил и не определяются методологией

Segments​

Третий уровень абстрагирования — согласно назначению в реализации.

• ui — UI-представление модуля (components, widgets, canvas, …);

• model — бизнес-логика модуля (store, effects/actions, hooks/contracts, …);

• lib — вспомогательные библиотеки;

• api — логика взаимодействия с API;

• config — модуль конфигурации приложения и его окружения.

Ниже приведу пример описания фичи авторизации.

# Сегменты могут быть как файлами, так и директориями
|
├── features/auth # Layer: Бизнес-фичи
| | # Slice Group: Структурная группа «Авторизация пользователя»
| ├── by-phone/ # Slice: Фича «Авторизация по телефону»
| | ├── ui/ # Segment: UI-логика (компоненты)
| | ├── lib/ # Segment: Инфраструктурная-логика (helpers/utils)
| | ├── model/ # Segment: Бизнес-логика
| | └── index.ts # | |
| ├── by-oauth/ # Slice: Фича «Авторизация по внешнему ресурсу»
| …

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

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

Заключение

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

Также если вам интересно в своем Telegram я время от времени выкладываю интересные находки по фронтенду. И всем чистой архитектуры.

Эта статья — перевод оригинальной статьи Ahmad Shadeed «First Look At The CSS object-view-box Property»

Также я веду телеграм канал “Frontend по-флотски”, где рассказываю про интересные вещи из мира разработки интерфейсов.

Вступление

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

В этой статье я познакомлю вас с новым CSS свойством object-view-box, предложенным Джейком Арчибальдом в начале этого года. Это позволяет нам обрезать или изменять размер HTML-элементов, таких как или

Проблема

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

В настоящее время мы можем решить это одним из следующих способов:

• Использование и его обёртывание в дополнительный элемент.

• Добавления изображения через background-image и изменение положения и размера.

Обертывание дополнительным элементом

Это распространенное решение этой проблемы, вот как это происходит:

• Обернул изображение в другой элемент (в нашем случае

  ).

• Добавил position: relative и overflow: hidden.

• Добавил position: absolute для изображения и поиграл со значениями позиционирования и размера для достижения результата.

figure {
position: relative;
width: 300px;
aspect-ratio: 1;
overflow: hidden;
border-radius: 15px;
}

img {
position: absolute;
left: -23%;
top: 0;
right: 0;
bottom: 0;
width: 180%;
height: 100%;
object-fit: cover;
}Применение изображения в качестве фона

В этом решении мы используем тег