DEV Community: Arif Balaev

Работа с внешними библиотеками

Arif Balaev — Mon, 10 Apr 2023 07:01:00 +0000

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

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

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

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

Тестирование: Используя фасад, мы можем мокать API внешней библиотеки в своих тестах, что делает процесс написания и поддержки тестов проще.
Безопасность: Контролируя, как наш код взаимодействует с внешней библиотекой, мы можем снизить риск уязвимостей безопасности, вызванных неожиданными взаимодействиями с библиотекой.
Производительность: Создавая фасад, мы можем оптимизировать использование библиотеки для улучшения производительности вашего кода.

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

Controlling External Libraries: Why It's Important for Developers

Arif Balaev — Sun, 09 Apr 2023 07:45:42 +0000

As a developer, it's important to have control over the external libraries that you use in your projects. One way to achieve this is by wrapping those libraries into self-created facades.

A facade is a design pattern that provides a simplified interface to a complex system. In the context of external libraries, a facade acts as a wrapper around the library's API, providing a simpler and more consistent interface to the library. By creating a facade for an external library, you can gain the following benefits:

Independence from the library's API: By using a facade, you can shield your code from changes to the external library's API. This means that if the library changes its API in a future version, you only need to update your facade to accommodate the changes, rather than updating all the code that uses the library directly.
Control over changes: When you wrap an external library in a facade, you have complete control over how you use the library. This means that you can choose which parts of the library to expose to your code, and how you want your code to interact with those parts. You can also add additional functionality to the facade, such as caching or error handling, without affecting the rest of your code.
Improved code maintainability: By using a facade, you can simplify your code and reduce its complexity. This makes it easier to maintain in the long term, as well as easier for other developers to understand and work with.

In addition to these benefits, there are several other reasons why you might want to create a facade for an external library. For example:

Testing: By using a facade, you can mock the external library's API in your tests, making it easier to write and maintain your test suite.
Security: By controlling how your code interacts with an external library, you can reduce the risk of security vulnerabilities caused by unexpected interactions with the library.
Performance: By creating a custom facade, you can optimize the library's usage to improve the performance of your code.

If you create a simpler and more consistent way to use an external library, it can help you manage your code better.

Therefore, it is recommended that you wrap all your external libraries in facades to achieve these benefits.

Критическое мышление

Arif Balaev — Mon, 27 Mar 2023 05:03:00 +0000

Мы ежедневно сталкиваемся с огромным потоком данных, новостей, мнений и рекомендаций.

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

На наших глазах происходит нечто невообразимое. Мы начинаем чаще спрашивать что-то у ChatGPT и его “друзей”, чем искать самостоятельно в гугле. И под всем этим мы не замечаем, что начинаем полностью доверять его ответам.

Здесь есть большой риск.

Хотя AI-модели и обучаются на огромных массивах информации, мы не можем быть уверены в том, что они не подвержены влиянию специально подобранных данных или предвзятых алгоритмов.

Навык критического мышления сейчас становится намного востребованнее, чем любой hard skill.

Попробуй следовать следующим правилам:

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

С появлением AI мы должны стать более эффективными, но не стоит бездумно делегировать всю ответственность на него.

Доверяй, но проверяй.

Критическое мышление - это нечто, что мы развиваем и совершенствуем на протяжении всей нашей жизни.
Начни с сегодняшнего дня.

Critical Thinking

Arif Balaev — Sun, 26 Mar 2023 14:36:31 +0000

We are bombarded daily with a huge amount of data, news, opinions and recommendations.

To avoid manipulation and logical errors, we need to learn how to carefully filter information. It is necessary to evaluate and analyze before accepting it as truth.

We are finding ourselves asking ChatGPT and its AI friends more often than searching Google ourselves these days. We are coming to fully trust their answers without realizing it.

This could be dangerous.

We cannot guarantee that AI models are unbiased, even though they are trained on massive amounts of data. Their algorithms or the information used to develop them could be wrong or outdated.

The skill of critical thinking is now becoming even more in demand than any hard skill.

Follow these simple rules:

Get clear understanding of message. If unsure, ask questions. Questions unlock understanding.
Don't just take things at face value. Look for proof, hard facts, expert opinions, statistics, and real examples to support what people say.
Consider other options. This will lead you to make more balanced and reasonable decisions.

As AI progresses, we must streamline our work. But we should not blindly hand over all accountability to AI.

Trust, but verify. Think critically.
Start now.

Почему React не реактивен?

Arif Balaev — Tue, 21 Mar 2023 13:57:55 +0000

Хотя в названии библиотеки React присутствует слово «РЕАКТ», её связь с парадигмой реактивного программирования куда интереснее, чем кажется на первый взгляд. Давайте разберемся, является ли React реактивным в классическом понимании этого слова.

Что такое реактивное программирование?

Для начала, что такое «реактивность»? В широком смысле, это парадигма программирования, ориентированная на автоматическое распространение изменений. Самый простой пример — электронная таблица. Вы меняете значение в одной ячейке, и все ячейки, которые от неё зависят, мгновенно пересчитываются. Им не нужно давать команду «обновись!», они сами реагируют на изменение источника данных.

В программировании эта идея чаще всего реализуется через потоки данных (streams) — асинхронные последовательности событий, которые происходят во времени. На эти потоки можно подписываться и реагировать на них.

Представьте ленту новостей в приложении. Новостной сервер — это Observable (наблюдаемый источник), который испускает события (новые статьи). Вы, как пользователь, — это Observer (наблюдатель), который подписан на этот источник и получает обновления, как только они появляются. Источник «проталкивает» (push) данные к наблюдателю. Это классическая, push-based модель реактивности, которую популяризировали такие библиотеки, как RxJS.

Ключевая особенность этой модели — полный контроль над потоком. События можно фильтровать (filter), преобразовывать (map) и даже группировать по времени (например, оператор bufferTime в RxJS может собрать все события за 2 секунды и выдать их одной пачкой).

Как работает React?

React построен вокруг простой идеи: ваш UI — это функция от вашего состояния (state). Изменилось состояние — изменился UI.

UI = f(state)

Событие из внешнего мира (клик мыши, ответ от сервера) вызывает изменение состояния через setState. Это, в свою очередь, запускает процесс обновления UI.

Внешне это выглядит как та самая реакция на изменения. Но дьявол, как всегда, в деталях. Нюанс заключается в том, КАК React решает обновить UI.

Когда вы вызываете setState, React не бросается сломя голову перерисовывать DOM. Вместо этого он планирует обновление. Он как бы ставит себе пометку: «Ага, состояние изменилось. Скоро нужно будет обновить интерфейс». Если вы вызовете setState несколько раз подряд в одном и том же обработчике, React окажется достаточно умён, чтобы объединить (сбатчить) их все в одно-единственное обновление.

Это фундаментальное отличие. В отличие от классической push-модели, где данные проталкиваются к подписчику, модель React можно назвать pull-based (основанной на запросе). React получает уведомление об изменении, но сам решает, когда запросить (pull) новое состояние и как наиболее эффективно обновить UI на его основе.

Так реактивен ли React?

Да, но он реализует свою, особую модель реактивности.

React реактивен в своей декларативной сути. Вы описываете, как должен выглядеть UI для определённого состояния, и доверяете React синхронизировать реальный DOM с этим описанием. В этом смысле он полностью соответствует широкому определению реактивности — UI автоматически реагирует на изменения данных.

Однако React не является «реактивным» в классическом, потоковом смысле, как RxJS. Он не предоставляет из коробки мощных инструментов для управления потоками событий. Его реактивность узко специализирована и нацелена на одну задачу: эффективное обновление дерева компонентов.

Пакетная обработка обновлений (batching) — это не то, что делает React «нереактивным». Как мы помним из примера с bufferTime в RxJS, управление потоком и группировка событий — это часть инструментария реактивных систем. Это лишь подчёркивает, что React выбрал конкретную стратегию управления изменениями, поставив во главу угла производительность и предсказуемость рендеринга.

Итог

Разобравшись в моделях реактивности, мы можем сделать вывод: React — это реактивная библиотека, но её реактивность не та, что в классических push-библиотеках вроде RxJS.

React использует pull-based модель с планированием обновлений, идеально заточенную под задачи построения пользовательских интерфейсов. Именно поэтому для сложных сценариев управления асинхронными потоками (например, при работе с WebSockets или сложными анимациями) разработчики часто комбинируют React с библиотеками вроде RxJS, получая лучшее из двух миров.

AI - это всего лишь инструмент, а не замена

Arif Balaev — Fri, 17 Mar 2023 15:28:03 +0000

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

В разработке мы всегда стремимся использовать что-то новое, потому что это новое экономит нам ресурсы (время, деньги, стресс).

Среды разработки развиваются, системы сборки конкурируют за миллисекунды, системы деплоя и хостинга пытаются сократить время доставки контента. Всё стремится быть эффективнее.

Что такое AI для разработчика?

Это такой же инструмент, который может значительно ускорить разработку. Не заменить разработчика, а ускорить (или даже свести к нулю) его рутинную работу. Google и StackOverflow - отличные примеры этого.

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

Но здесь есть один важный момент. Чтобы это работало и чтобы мы делегировали рутинные задачи AI, мы должны понимать, что он пишет.

Программисты никуда не денутся. Простые сайты и до AI можно было создавать через Тильду или no-code решения людям, которые ничего не понимают в разработке.

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

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

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

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

AI — это всего лишь инструмент, а не замена. Сейчас происходит переходный период. Кто раньше его освоит, будет намного эффективнее тех, кто не освоил его на текущем рынке. Пользуйтесь этим!

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

Не стой на месте 🤌

Arif Balaev — Wed, 15 Mar 2023 19:06:26 +0000

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

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

Наше развитие зависит от задач, которые мы решаем.

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

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

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

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

3 вещи, которые продуктовые фронтенд разработчики часто недооценивают

Arif Balaev — Mon, 13 Mar 2023 08:09:40 +0000

Мы привыкли считать, что фронтенд разработчик работает только с HTML, CSS и JS для клиентской части сайта. Но на самом деле он работает и отвечает за гораздо большее.

1️⃣ Дизайн

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

Изучай UI и UX. Не будь только исполнителем.

2️⃣ Бэкенд

Из каких компонентов состоит бэкенд? Какие задачи обычно решают бэкенд разработчики?

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

3️⃣ Продукт

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

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

System

Arif Balaev — Thu, 09 Mar 2023 05:20:16 +0000

Я эмоциональный человек.

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

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

Для начала разберемся, как устроена система.

Она принимает данные, делает с ними что-то (надеюсь) полезное и возвращает обработанный результат. При этом ее работу можно настраивать.

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

Шик! Выпьем кофе и двинемся дальше.

Идеальная система редко строится с первого раза. Нам нужно как-то понимать, где она требует улучшений, а где и так отлично справляется с задачей. Всё линейно.

"Если вы не можете измерить это, вы не можете управлять им" - Питер Друкер.

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

Допустим, я построил систему и покрыл её показателями. В чём прикол?

Построив систему один раз, мы исключаем эмоциональные решения, потому что сама система говорит нам, что и как делать. Всё происходит намного быстрее и исключает много рисков. Гениально!

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

Подумай, на что ты тратишь много времени и эмоций. Можно ли это систематизировать?

Дай знать, что думаешь по этому поводу 👇

Overengineering

Arif Balaev — Thu, 02 Mar 2023 13:53:48 +0000

Over engineering - проблема каждого.
Термин подразумевает создание более сложных вещей, чем этого требовалось. Ресурсы тратятся на менее важные вещи. Время проходит неэффективно. Ожидания не оправдываются, и ты огорчаешься. Узнаешь себя?

Откуда это берется?

Задача нечетко определена. Нет ясности, зачем ты это делаешь. Какую проблему решаешь? Решаются другие проблемы или тратится время на ненужное.
Плохая коммуникация. Бизнес меняется. Завтра появляются новые требования или задача устаревает. Если мы вовремя не получим обратной связи, мы потеряем время.
Перфекционизм. Все готово, но не идеально. Мы тратим время на поиск ошибок и задерживаем сроки.
Иррациональное мышление Мы пытаемся предвидеть будущее и облегчить работу. "Один раз сделаю и больше не буду трогать годами." Но мы смотрим слишком далеко и тратим время на "что если".

Последствия

Тратим больше времени. Время = деньги. Потеряли время - потеряли деньги.
Наше "Изобретение" нужно поддерживать. Чем дальше от даты создания, тем меньше помним, как это работает.
Не уложились в сроки. Задача устарела. Снижается мотивация и эффективность.

Выход

Не выдумывай и не планируй слишком далеко. Разработка решает проблемы бизнеса. Сделай требования прозрачными. Дай бизнесу, что он хочет, в кратчайшие сроки и получи обратную связь. Думай над оптимизацией, если это актуально. Почитай про Закон Парето.
Обзаведись критическим мышлением. Что мы решаем? Какой самый важный сценарий? Можно ли сделать решение проще и выполнить требования? Почему мы выбрали этот подход? Какие альтернативы мы могли бы выбрать?

Привет, CSS Cascade Layers (Каскадные слои)

Arif Balaev — Wed, 16 Feb 2022 14:43:49 +0000

Вольный перевод статьи Hello, CSS Cascade Layers от Ahmad Shadeed

Мой twitter

Одной из наиболее распространенных путаниц в CSS является специфичность (specificity) при написании стилей. Например, меняя значение display для элемента никогда не сработает, если другой элемент в каскаде переопределяет его по причине более высокой специфичности. Или когда какой-то элемент имеет !important. Обычно это происходит, когда кодовая база растет и мы не структурируем CSS по пути избежания (или сокращения) таких проблем.

Чтобы преодолеть проблемы с каскадом и специфичностью, нам нужно быть осторожными в местах, где мы пишем CSS. В малых проектах всё может быть в порядке, однако в больших проектах задача может оказаться трудоёмкой. В результате стали появляться различные методы для организации CSS и, соответственно, сокращения проблем с каскадом. Первые три, что приходят мне на ум, это BEM, Smacss от Jonathan Snook и Inverted Triangle CSS от Harry Roberts

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

Проблема

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

У нас есть кнопка с двумя стилями: default и ghost. В HTML мы будем их использовать следующим образом:



<footer class="form-actions">
    <button class="button">Save edits</button>
    <button class="button button--ghost">Cancel</button>
</footer>

Всё отлично работает в этом случае. Но что, если у нас появился третий вариант кнопки и мы не можем написать его сразу после селектора .button?

.button идёт после .button--facebook. В итоге он будет переопределён. В данном случае можно найти решение через повышение специфичности для .button-facebook, например:



.some-parent .button--facebook {
    background-color: var(--brand-fb);
    color: #fff;
}

Или можно сделать так (не повторяйте это в домашних условиях!):



.button--facebook {
    background-color: var(--brand-fb) !important;
    color: #fff !important;
}

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

Введение в CSS Cascade Layers (каскадные слои)

Каскадные слои это новая CSS фича, которая позволяет разработчикам получать больший контроль над написанием CSS в больших проектах. По словам автора спецификации Miriam Suzanne:

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

Давайте применим каскадные слои для предыдущего примера.

Для начала надо обозначит слой. Чтобы это сделать, мы напишем @layer.



@layer components { }

Я обозначил слой с именем components. Внутри этого слоя мне нужно определить default стили кнопки.



@layer components {
    .button { 
        color: #fff;
        background-color: #d73a7c;
    }
}

Шик. Далее нужно добавить слой для вариаций.



@layer components {
    .button { 
        color: #fff;
        background-color: #d73a7c;
    }
}

@layer variations {
    .button--ghost {
        background-color: transparent;
        color: #474747;
        border: 2px solid #e0e0e0;
    }
}

Вот визуализация слоев. Они аналогичны слоям Photoshop, поскольку то, что определено последним в CSS, будет первым в списке слоев визуально.

В нашем примере variation слой определен последним, поэтому он будет иметь более высокий приоритет, чем слой components.

Существует также другой способ организации того, какой слой переопределяет другой, путем одновременного определения слоев.



@layer components, variations;

Вернёмся к нашему примеру. Основная проблема была в том, что нам нужно было создать новую вариацию кнопки, поместив её в место, где вариация бы имела меньшую специфичность (до .button). С каскадными слоями мы можем добавить этот кусок в слой variations.



@layer components, variations;

@layer components {
    .button { 
        color: #fff;
        background-color: #d73a7c;
    }
}

@layer variations {
    .button--ghost {
        background-color: transparent;
        color: #474747;
        border: 2px solid #e0e0e0;
    }

    .button--facebook {
        background-color: var(--brand-fb);
    }
}

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

Обратите внимание, как каждая кнопка живет в слое. Порядок соответствует определению @layer вверху.

Если поменять порядок, то слой components будет переопределять слой variations и default стили "победят".

Добавление стилей в слои

В каскадных слоях браузер комбинирует стили из одних и тех же селекторов @layer и считывает их сразу в соответствии с их порядком.

Рассмотрим следующее:



@layer components, variations;

@layer components {
    .button {..}
}

@layer variations {
    .button--ghost {..}
}

/* 500 lines later */
@layer variations {
    .button--facebook {..}
}

Браузер поместит .button--facebook прямо после .button--ghost в слое variations. Изображение для большей ясности:

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

Это самый важный вопрос, чтобы задуматься над новой фичей CSS. Согласно Can I Use на момент написания этой статьи, она поддерживается в Firefox, Chrome, Safari TP. Можем ли мы использовать их в качестве enhancement? Нет, мы не можем. Если только мы не используем полифилл Javascript (которого пока нет).

Где в каскаде живут слои?

Чтобы ответить на этот вопрос, давайте рассмотрим каскад в CSS.

CSS каскад упорядочен следующим образом (первые имеют больший приоритет):

Origin и importance
Инлайн стилизация
Слои
Специфичность
Порядок в коде Рассмотрим следующий рисунок. Чем толще линия, тем приоритетнее стиль в каскаде.

Origin и importance

Это две разные (но связанные) вещи, так что разберем каждую по-отдельности.

Origin стили приходят из следующих вещей (сначала более приоритетные):

Стили разработчика (AKA авторские)
Стили пользователя
Стили браузера

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

Посмотрим пример.



html {
    font-size: 16px;
}

Если пользователь попробует поменять стили браузера (font-size по-умолчанию в данном примере), то CSS выше всё равно его переопределит, так как стили разработчика приоритетнее пользовательских и браузерных.

Это плохая практика для accessibility (доступности). Пожалуйста, не делайте этого в продакшене. Я просто добавил это ради объяснения origin стилей.

Что касается стилей браузера, они предназначены для user agent стилей. Например, по-умолчанию стиль <button> выглядит по-разному в браузерах. Мы можем его переопределить, как вы уже догадались, потому что стили разработчика имеют преимущество над стилями браузера.

Если вы посмотрите на дефолтные стили кнопки, то увидите user agent stylesheet, которые как раз и показывают стили браузера у кнопки.

Всё вышеописанное касалось стандартных/нормальных/обычных правил. Это значит, что они не имеют ключевого слова !important. В случае, если оно есть, то порядок приоритета будет следующим:

Стили браузера с important
Стили пользователя с important
Стили разработчика с important
Обычные стили разработчика
Обычные стили пользователя
Обычные стили браузера

Инлайн (inline) стили

Если элемент имеет инлайн стили, то у него большая специфичность по сравнению с другими правилами того же importance уровня.

В примере ниже, цвет кнопки будет #fff так как инлайн стили в приоритете.



<style>
button {
    color: #222;
}
</style>

<button style="color: #fff;">Send</button>

От себя: Importance обеих стилей относятся к "Обычные стили разработчика", следовательно далее по уровню проверяется inline. Если бы был у них разный уровень importance, например color: #222; !important, то это правило отнеслось бы к категории "Стили разработчика с important", что приоритетнее, чем "Обычные стили разработчика". Тогда был бы цвет #222.

Слои

О, привет слои! Это новый гость в каскаде. Каскадные слои имеют больший приоритет, чем специфичность селектора. В следующем примере сможете ли вы угадать размер шрифта элемента p в слое custom?



@layer base, custom;

@layer base {
  #page .prose p {
    font-size: 1rem;
  }
}

@layer custom {
  p {
    font-size: 2rem;
  }
}

Шрифт будет 2rem. В каскадных слоях не важна специфичность. Она будет проигнорирована, если элемент переопределен последующим слоем.

Специфичность

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

Вот простой пример. .button внутри .newsletter имеет большую специфичность чем просто .button. В итоге верхнее правило будет переопределено.



.button {
    padding: 1rem 1.5rem;
}

/* Побеждает */
.newsletter .button {
    padding: 0.5rem 1rem;
}

Порядок в коде

Наконец порядок вступает в силу. Когда два элемента имеют одинаковую специфичность, тогда их порядок в документе определяет победителя (тот, что ниже "сильнее").



.newsletter .button {
    padding: 1rem 1.5rem;
}

/* Побеждает */
.newsletter .button {
    padding: 0.5rem 1rem;
}

Теперь у вас есть понимание, где слои находятся в каскаде. Обратимся к нескольким примерам их использования.

Применение каскадных слоёв

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

Переключение UI темы

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



@layer base, elements, objects, components, pages, themes;

У меня есть несколько слоёв и последний это themes. Слой themes может в себе иметь несколько слоев (да, каскадные слои поддерживают вложенность).

Обратите внимание, что вверху я определил @layer custom, default. default будет переопределять custom.



@layer base, elements, objects, components, pages, themes;

@layer themes {
    @layer custom, default;

    @layer default {
        :root {
            --color-primary: #1877f2;
        }
    }

    @layer custom {
        :root {
            --color-primary: #d73a7c;
        }
    }
}

Если вам потребуется переключить темы, нужно просто поменять порядок слоев в первой строчке @layer themes.



@layer base, elements, objects, components, pages, themes;

@layer themes {
    /* Custom is active */
    @layer default, custom;

    @layer default {
        :root {
            --color-primary: #1877f2;
        }
    }

    @layer custom {
        :root {
            --color-primary: #d73a7c;
        }
    }
}

Сторонний CSS

Я взял пример, в котором используется карусель flickity. Посмотрите на все ! important значения.



.flickity-page-dots {
    bottom: 20px !important;
}

.flickity-page-dots .dot {
    background: #fff !important;
    opacity: 0.35 !important;
}

.flickity-page-dots .dot.is-selected {
    opacity: 1 !important;
}

С каскадными слоями мы можем добавить сторонний CSS перед слоем компонентов. Мы можем импортировать внешний файл CSS и задать ему слой.



@layer base, vendors, components;

@layer base {
    /* Base styles */
}

/* Import a .css file and assign it to a layer */
@import url(flickity.css) layer(vendors);

@layer components {
    .flickity-page-dots {
        bottom: 20px;
    }

    .dot {
        background: #fff;
        opacity: 0.35;
    }

    .dot.is-selected {
        opacity: 1;
    }
}

Меньше переживать об ошибках специфичности

Допустим, у нас есть компонент списка, и нам нужен вариант, в котором список имеет меньший margin.



<ul class="list">
    <li class="list__item list__item--compact">Item 1</li>
    <!-- Other items -->
</ul>

Поскольку псевдоселектор :not придает элементу большую специфичность, его нельзя переопределить без повторного использования :not. Рассмотрим следующее:



/* Побеждает */
.list__item:not(:last-child) {
    margin-bottom: 2rem;
    outline: solid 1px #222;
}

.list__item--compact {
    margin-bottom: 1rem;
}

.list__item--compact не будет переопределять .list__item^ так как последний имеет большую специфичность из-за использования :not. Чтобы все заработало, нам нужно написать следующее:



.list__item:not(:last-child) {
    margin-bottom: 2rem;
    outline: solid 1px #222;
}

.list__item--compact:not(:last-child) {
    margin-bottom: 1rem;
}

Посмотрим, как с этой проблемой справятся каскадные слои.

Представим, что @layer list содержит base и overrides слои. В overrides я написал альтернативный способ, и он работал, как и ожидалось, поскольку overrides является последним слоем.



@layer list {
    @layer base, overrides;

    @layer base {
        .list__item:not(:last-child) {
            margin-bottom: 2rem;
        }
    }

    @layer overrides {
        .list__item--compact {
            margin-bottom: 1rem;
        }
    }
}

Вложенные компоненты

В данном примере у нас есть список действий (лайк, комментарий) для основного элемента социальной ленты и еще один список для каждого комментария.

Иконка у блока элемента ленты имеет размер 24px. В компоненте комментариев размер меньше.



@layer feed, comments;

@layer feed {
  .feed-item .c-icon {
    width: 24px;
    height: 24px;
  }
}

@layer comments {
  .comment__icon {
    width: 18px;
    height: 18px;
  }
}

Обратите внимание, что .feed-item .c-icon имеет большую специфичность, чем .comment__icon, но в этом фишка использования каскадных слоев!

Служебный (утилитный) CSS

Мы привыкли добавлять !important к служебным классам CSS, чтобы они всегда применялись к элементу. С каскадными слоями мы можем разместить слов на последнем месте.

Рассмотрим следующий пример. У нас есть header страницы с утилитным классом p-0. Мы хотим сбросить padding до 0.



<div class="c-page-header p-0">
    <!-- Content -->
</div>

Вот как это выглядит с каскадными слоями.



@layer base, vendors, components, utils;

@layer components {
    @layer page-header {
        .c-page-header {
            padding: 1rem 2rem;
        }
    }
}

@layer utils {
    .p-0 {
        padding-left: 0;
        padding-right: 0;
    }
}

Больше подробностей о каскадных слоях

Стили без слоя имеют большую специфичность

Если есть стили CSS, которые не назначены слою, то они будут добавлены к неявному последнему слою.

Рассмотрим следующий пример.



.button {
    border: 2px solid lightgrey;
}

@layer base, components;

@layer base {/* Base styles */}

@layer components {
    .button {
        border: 0;
    }
}

В этом примере правило .button определено без @layer, однако браузер поместит его в неявный слой.



@layer base, components;

@layer base {/* Base styles */}

@layer components {

    .button {

        border: 0;

    }

}

/* Implicit layer */

@layer {

    .button {

        border: 2px solid lightgrey;

    } 

}

Вывод

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

Для дальнейшего изучения

-The Future of CSS: Cascade Layers by Bramus Van Damme
-Getting Started With CSS Cascade Layers by Stephanie Eckles
-Cascade layers are coming to your browser by Una Kravets

NPM dependencies. В какую категорию импортировать пакет?

Arif Balaev — Tue, 23 Nov 2021 20:08:38 +0000

Какие есть категории зависимостей?

Обратимся к официальной документации от NPM

dependencies
devDependencies
peerDependencies
peerDependenciesMeta
bundledDependencies
optionalDependencies

Отличия

dependencies - то, что реально нужно проекту в production режиме. Например, утилитные библиотеки react, lodash, classnames итп
devDependencies - нужны во время разработки (dev). К таким библиотекам могут отнестись:
1. библиотеки форматирования - eslint, prettier, ...
2. сборщики: webpack, rollup, ...
3. babel
4. всё, что связано с тестированием
5. другие библиотеки, такие как storybook
peerDependencies - нужен для публикации своего пакета. В эту категорию попадают зависимости, без которых ваш пакет будет работать некорректно. Проекту, устанавливающему ваш пакет нужно убедиться, что у него загружены все зависимости из peerDependencies
peerDependenciesMeta - мета-данные для peerDependencies. Например, чтобы сделать какую-то зависимость опциональной. Хотя, тогда не понятно, зачем она находится в peerDependencies.
bundledDependencies - выполняют схожую функциональность, что и обычные dependencies - входят в финальную сборку. Но они решают следующий пример: проект использует пакет1, в котором есть зависимость пакет2 внутри bundledDependencies. Если по каким-то причинам пакет2 будет снят с пубикации и до него не будет доступа, то пакет1 будет всё равно иметь эту зависимость внутри себя до тех пор, пока явно не почистить node_modules или не убрать пакет2 из зависимости пакета1.
optionalDependencies - то же, что и dependencies, только в случае ошибки их подгрузки сборка не падает

Перед тем как импортировать зависимость в свой проект, не забудьте спросить себя "А она точно мне нужна?". Может быть вам нужна какая-то малая ее часть, которую вы сможете написать самостоятельно. Но выбор между собственной имплементацией и сторонней - это уже отдельная тема.

twitter @balaevarif