Как открыть ссылку в новом окне или вкладке

Чтобы ссылка открывалась в новом окне или вкладке, достаточно добавить к тегу <a> атрибут target="_blank":

<a 
 href="https://t.me/prog_way_blog" 
 target="_blank"
 rel="noopener noreferrer"
>
 Ну чё-то какой-то канал в телеге
</a>

Атрибут target="_blank" сообщает браузеру, что ссылку нужно открыть в новой вкладке. И также стоит обратить внимание на атрибут rel. Он предотвращает передачу информации о странице, с которой была открыта ссылка, а также защищает от потенциальных уязвимостей

Накидайте побольше китов 🐳 на пост и, если это будет актуально, сделаю отдельный пост с разбором noopener noreferrer и зачем оно надо

Если же вы сомневаетесь, ставить их или нет — ставьте всегда

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #theory #web #useful

Разделение чанков в Vite

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

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

Чанк — собранные блоки кода, в виде которых пользователь загружает себе ваше приложение.

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

Выглядеть конфигурация может вот так:

build: {
  rollupOptions: {
    output: {
      manualChunks: {
        core: [
          'react', 
          'react-dom', 
          'react-router-dom'
        ],
        network: [
          'axios', 
          '@tanstack/react-query'
        ],
        utils: [
          'classnames', 
          'dayjs', 
          'escape-html', 
          'tailwind-merge', 
          'zustand',
           '@loadable/component'
        ],
        table: [
          '@tanstack/react-table', 
          '@tanstack/react-virtual'
        ],
        chart: [
          'reactflow', 
          '@dagrejs/dagre'
        ],
        icons: ['@ant-design/icons'],
        ui: [
          '@chakra-ui/react', 
          'chakra-react-select', 
          'framer-motion', 
          'prismjs', 
          'react-simple-code-editor'
        ],
      },
    },
  },
}

Не очень красиво, но как есть. В единый чанк стоит объединять те библиотеки, что не могут работать друг без друга, например чанк core . Также есть ещё и частотная группировка — когда легковесные библиотеки собирают в один чанк, чтобы быстро загрузить их все, так как понадобятся они на всех страницах, например чанк utils

Что в итоге? Скорость загрузки приложения можно значимо увеличить. Для отрисовки, например, страницы авторизации, нам не нужны таблицы, графики и прочие красивости — загрузим чанки core и network, остальное нам не нужно. Остальные чанки мы можем загрузить по мере необходимости, используя асинхронные инструменты загрузки. Это могут быть @loadable, который рекомендует команда React или же вовсе обычный import.

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

Выглядеть это будет примерно так:

const About = lazy(() => import("./pages/about")); // для реакт компонентов

// более сложный пример импорта компонента с @loadable/components
const PageComponent = loadable((props) => import(`./pages/${props.page}`), {
  fallback: <div>Page is Loading...</div>,
  cacheKey: (props) => props.page
});

async function foo() {
  const utils = await import("./utils.js") // для, например, утилсов
}

Более подробно о manualChunks можно прочитать в доке rollup

Спасибо за прочтение, для меня это важно ❤️

@prog_way_blog — чат — #theory #web #useful

Как скачать файл с сайта

У тега ссылки <a> есть очень удобный атрибут download, который позволяет скачать любой файл с сайта. Выглядит его использование примерно так:

<a
    download
    href="https://.../files/example.zip"
>
    Скачать файл
</a>

Также в атрибут download можно передать собственное название для файла, например:

<a
    download="новое_название_файла.zip"
    href="https://.../files/example.zip"
>
    Скачать файл
</a>

Стоит учитывать, что скачивать файлы мы можем только с тех хостов, в которых выполняются CORS политики для нашего сайта. Более подробно о CORS я писал как у себя в канале, так в статье на doka.guide

Сейчас этот атрибут уже достиг порога поддержки в более чем 97% согласно caniuse и не поддерживается полноценно только в IE

Ребята, если у вас есть идеи о чём ещё вам было бы интересно прочитать, обязательно отпишитесь в чатик или мне в личку.

Всем добра)

@prog_way_blog — чат — #theory #web #useful

CSS для печати страниц

Несколько лет назад я делал пет-проект — конструктор резюме. Кейс был такой, что хотелось сразу же печатать созданное резюме при нажатии сочетания клавиш Ctrl+P в браузере. Но проблема в том, что помимо самого резюме на печать попадало не только само резюме, а все кнопки, поля и прочие элементы страницы для его настройки. Такие кейсы можно решать при помощи CSS медиазапроса @media print:

@media print {
    /* стили для печати */
}

То есть во время печати мы можем скрыть все ненужные элементы:

@media print {
  .navbar, .footer, .controls {
    display: none;
  }
}

Ну или ещё проще:

@media print {
  .no-print {
   display: none;
  }
}

А сам класс .no-print проставлять на все скрываемые при печати элементы.

Также есть ещё специальные CSS свойства печати, например, break-inside, которое дополнительно настраивает можно ли переместить блок со страницы на страницу при печати, что особенно актуально для целостных блоков типа “контакты” в резюме. Если указать break-inside: avoid, то такой элемент не сможет быть расположен на двух страницах сразу, а перенесётся весь, если для него не хватает места.

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

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #theory #code #web #useful

Разница между CommonJS и ES Modules

Если по простому, то CommonJS и ES (ECMAScript) Modules — это два способа импорта и экспорта чего либо из файлов в JavaScript

CommonJS — относительно старый API, который был разработан для NodeJS. Выглядит он следующим образом:

// Экспорт
module.exports = function() {
    console.log(...);
};

// Импорт
const module = require('./module');
module();

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

Для браузера, синхронная загрузка — крайне неудачный подход из-за блокировки интерфейса в момент загрузки. Поэтому в браузере использовать CommonJS — моветон, лучше использовать ES Modules

ES Modules — это подход, который в язык принес ECMAScript 2015 (ES6). Он задумывался как замена устаревшему CommonJS и выглядит так:

// Экспорт
export function foo() {
    console.log(...)
}

// Импорт
import { foo } from './module.js';
foo();

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

Также ES Modules могут использоваться не только в браузере, а и в NodeJS, начиная аж с 12 версии. Как же давно это было🥲

ИМХО, в современной разработке от CommonJS можно отказаться как от рудимента. Я стараюсь использовать модули по максимуму

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #theory #javascript #code

Как убрать стили на под-дереве — мини-задача с реального проекта

Недавно был следующий кейс: в долгоживущий проект интегрировали tailwind со своими обнуляющими стилями. Эти стили очень нужны проекту, но на одной из страничек есть Rich-текст, приходящий с апишки, который, к сожалению, частично завязан на браузерные стили, и, после добавления обнуляющих стилей tailwind, весь поплыл

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

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

Обнулить все стили на под-дереве можно с помощью CSS свойства all. Выглядеть это может так:

.tailwind-reset-styles * {
  all: revert;
}

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

Далее полученный класс .tailwind-reset-styles вешаем на родительский тег, все под-дерево которого уже будет со сброшенными ненаследуемыми стилями. Это, наверное, самое элегантное и быстрое решение, что можно придумать в этой ситуации

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

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #theory #web #code

Про платные курсы и менторинг

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

Какие курсы посоветуешь купить?

Отвечаю на этот вопрос постом: никакие

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

Я и сам занимаюсь своего рода "образовательным", прости господи, контентом, поэтому посмотреть такое бывает и правда занятно

И ничего невероятного там, как очевидно, я не увидел ни разу

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

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

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

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

И, к счастью, особенно front-end сообщество активно делится своим опытом с новичками и делает это совершенно бесплатно. Можно использовать даже тот же roadmap.sh, где, на самом-то деле, реально неплохая структура, которой можно следовать до определенного уровня

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

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

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

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

Чаще всего, частный менторинг — это не просто годнота с индивидуальным подходом, это ещё и сильно дешевле курсов

У меня у самого был ментор, я сам был ментором — я знаю, что это такое

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

Если вам это как-то интересно, поставьте эмоцию кита 🐳 на пост или напишите в личку, мне интересен спрос и ваше виденье ситуации

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #blog #useful

Что такое виртуализация?

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

Я очень рекомендую TanStack Virtual для этой задачи. Мне уже удалось применить его на нескольких проектах и никаких проблем он не вызывал

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

Так вот, зачем отображать все 10.000 сразу, если на экране в лучшем случае поместиться треков 20-30? Давайте рисовать только первые, например, 50 треков, а дальше следить за тем что видит пользователь — за его скроллом. Если пользователь прокрутит ещё на 20 строк вниз, то мы нарисуем следующие 20 строк, а первые 20 удалим из вёрстки

Под коробкой все виртуализаторы как раз этим и занимаются:
1. Определяют какие элементы видны пользователю сейчас
2. Определяют сколько элементов скрыто над и под окном просмотра

Чаще всего это реализуют через события scroll на контейнере или через IntersectionObserver, подробности реализации для особо любопытных всегда доступны в сорсах библиотек (в TanStack Virtual можете начать с функции observeElementRect)

Виртуализация может пригодиться в огромном срезе приложений, поэтому очень советую с ней ознакомиться заранее, если вы ещё не успели

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #theory #javascript #code #react

Как браузер понимает, что нужно закешировать?

Частый вопрос с собесов, который, к тому же, часто может пригодиться и на практике

Кеширование — это способ оптимизации загрузки через хранение копий файлов на вашем устройстве, чтобы ускорить доступ к ним в будущем. Это могут быть HTML, CSS, JS файлы, изображения, шрифты и всё остальное

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

Самый простой способ контролировать кеширование в браузере — это напрямую сказать браузеру что можно кешировать и как долго это можно сделать. Реализуют это обычно через специальные HTTP заголовки Cache-Control и Expires:

Cache-Control заголовок может иметь несколько значений:

— no-cache — браузер проверяет актуальность ресурса на сервере при каждом запросе

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

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

Чаще всего это значение используют с ресурсами, что изменяются часто

— no-store — полностью запрещает хранить ресурс в кеше. Особенно полезно для чувствительных данных, типа истории переводов в банке

— public, max-age=31536000 — пример агрессивного кеширования, где ресурс можно хранить в кеше до одного года (максимальное время max-age указывается в секундах). Например, это может быть применено к логотипу компании, который редко меняется

Также есть ещё один заголовок — Expires. Он указывает точную дату и время, до которого ресурс считается актуальным и может быть использован из кеша без проверки на сервере:

Expires: Wed, 21 Oct 2024 07:28:00 GMT

Этот заголовок говорит браузеру, что ресурс может использоваться 
из кеша до 21 октября 2024 года 07:28:00 по времени GMT

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

Если нужно кешировать ресурс по времени, то обычно используют Cache-Control и его параметр max-age, так как в этом случае дата окончания кеширования рассчитывается относительно настроек времени на устройстве пользователя

Кратко:

Чаще всего браузер понимает что кешировать через специальный заголовок Cache-Control

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #theory #web #data

Как менять состояние вкладки по интервалу

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

Для реализации нам необходимо создать состояния, между которыми мы хотим перемещаться:

const states = [
  { title: "Мессенджер", icon: Favicon1 },
  { title: "Новое сообщение", icon: Favicon2 },
]

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

const [stateIndex, setStateIndex] = useState(0);

// раз в секунду переходим на следующее состояние
useEffect(() => {
  const intervalId = setInterval(() => {
    setStateIndex((prevIndex) => (prevIndex + 1) % states.length);
  }, 1000);

  return () => clearInterval(intervalId);
}, []);

И в зависимости от текущего состояния изменяем параметры вкладки:

useEffect(() => {
  const link = document.querySelector("link[rel~='icon']");
  const title = document.querySelector("head title");

  if (link) {
    link.href = states[stateIndex].icon;
    title.textContent = states[stateIndex].title;
  }
}, [stateIndex]);

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

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #code #web #theory #javascript #react

Примерно вот так это может в итоге выглядеть

Как определить, активна ли вкладка у пользователя?

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

Во-первых, у объекта document есть свойство hidden, которое указывает открыта ли вкладка на экране пользователя в конкретный момент времени:

// если true, значит вкладка работает в фоне
document.hidden // true 

// вкладка открыта на весь экран
document.hidden // false

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

Чаще всего используется второй способ, а именно отслеживание события visibilitychange:

document.addEventListener("visibilitychange", function() {
  if (document.hidden) {
    console.log("Вкладка неактивна")
  } else {
    console.log("Вкладка активна")
  }
})

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

Зачем это можно использовать? Да абсолютное множество применений:
— дополнительно сохранять данные на закрытие вкладки
— выключать аудио/видео при скрытии вкладки
— сбор аналитики
— и куча всего ещё

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #code #web #theory #javascript

"Тяжёлые" анимации

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

И для того, чтобы разобраться в нюансах, стоит помнить, что отрисовка контента страницы происходит в несколько этапов, таких как получение ресурсов, парсинг HTML и CSS, создание Render Tree и так далее. Более подробно можно прочитать в отличной статье на доке

Мы же сконцентрируемся на Layout и Paint фазах, их я кратко напомню:

- Layout — фаза отрисовки, в которой браузер рекурсивно проходится по заранее полученному Render Tree и рассчитывает позиции и размеры элементов относительно друг друга для их корректного расположения внутри вьюпорта

- Paint — по полученным позициям и размерам браузер рисует конкретные пиксели конкретных цветов

Также помним, что Paint без Layout не бывает, а если вызывается пересчёт Layout, то и в фазу Paint мы обязательно попадём, причём с нуля

Так вот, к чему это я: анимация любого свойства, которое так или иначе влияет на расположение элементов на странице будет вызывать Layout и Paint на каждый фрейм анимации, а сам по себе процесс отрисовки — это далеко не дёшево

Часто можно столкнуться с анимацией, когда какой-то элемент на странице (изображение, текст или ещё что-то) плавают по странице в зависимости от положения курсора. Там анимация беспрерывна, и если реализовать подобную анимацию через свойства top и left, например, то фазы Layout и Paint будут крутиться каждый раз, когда вы двигаете курсором, и из-за долгих рассчётов вся анимация будет дёрганной

Решается это просто — на помощь приходит Compositing

Compositing — это способ вынести все вычисления для рендера в отдельное ядро

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

Браузеры умеют применять это и самостоятельно, но у нас и у самих есть возможность вынести элемент на отдельный слой: использовать transform

Анимацию плавающего элемента нужно переделать с top и left на transform, и вот почему:

top и left триггерят Layout и Paint для всего потока, а может и всей страницы. transform выносит элемент в отдельный поток, что уменьшает объём вычислений и делает страницу более отзывчивой

Таким образом, к тяжёлым свойствам можно отнести все, что триггерят Reflow (повторный вызов Layout фазы) и Repaint:

Reflow триггерят анимации: width, height, top, left, font-size, border-width, margin, padding и так далее — все свойства, что могут влиять на расстановку элементов на странице

Repaint триггерят анимации: color, background-color, outline, visibility — все свойства, что влияют на отображение, но не на позицию элемента

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

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #web #theory

Немного о __proto__ и prototype в JavaScript

__proto__ — это внутреннее свойство любого объекта или примитива в JavaScript, которое ссылается на объект, от которого он наследует свойства и методы

prototype — это свойство функций-конструкторов (или классов), которое используется для определения объектов, которые будут выступать в роли прототипов для всех экземпляров, созданных этим конструктором

В чём разница?

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

prototype есть только у функций-конструкторов (и классов) и используется для задания свойств и методов, которые будут доступны всем экземплярам, созданным с помощью этого конструктора

Если рассмотреть в коде, то получим следующее:

const name = "Denis"
const surname = "Putnov"

name.__proto__ === String.prototype // true
name.prototype // undefined
name.__proto__ === surname.__proto__ // true

const age = 23

age.__proto__ === Number.prototype // true
age.prototype // undefined

То есть, по факту, свойство __proto__ можно назвать некоторым костылём языка, благодаря которому мы можем понять с помощью чего конкретно был создан наш новый объект

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

В примере выше, мы при помощи __proto__ можем увидеть, что name в итоге создан при помощи прототипа String

Зачем всё это нужно? Для корректной работы прототипного наследования, конечно же. Рассмотрим ещё один пример кода:

const channel = {
  name: "progway"
}

channel.toString()
// как же javascript'у понять, откуда взять метод?
// под капотом вызывается это вот так:

(channel.__proto__).toString()

// а мы знаем, что channel.__proto__ === Object.ptototype
// поэтому выглядеть вызов будет примерно вот так

Object.prototype.toString.call(channel)

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

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

Если моё объяснение не очень понятно, то есть отличный видос у камасутры на эту тему, где всё разжёвано максимально понятно, советую

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #web #javascript #theory #code

Как я использую шину событий

Шина событий — это паттерн, который используется для взаимодействия различных компонентов системы не напрямую, а через некоторый посредник — саму шину

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

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

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

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

Главным минусамом я бы назвал некоторую непрозрачность: порой бывает сложно отследить куда и как протекают данные, особенно в больших приложениях, но ИМХО это относительно легко решается базовой организацией кода

Лично мне уже не раз доводилось использовать шину в проде. Нравится она мне своей простотой и тем, что позволяет легко соединять несоединяемое. В связке с реактом, можно легко избавиться от лишних ререндеров или, например, от prop-drilling'a

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

Я создаю отдельный файл для инициализации канала

export const {useEvent: useSpecificEvent, ...specificEventChannel} = createEventChannel<{
  event: (options: Foo) => void;
}>()

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

// где угодно: публикация события в шину
specificEventChannel.emit('event', options)

// в react-компоненте: реакция на событие
useSpecificEvent('event', (options) => {
  ...
})

Конечно же, реагировать на событие в шине можно не только в компонентах: можно вообще где угодно. Для этого в specificEventChannel есть дополнительные функции on, off и once для подписки, отписки и единоразовой реакции соответственно

Вся "магия" тут заложена внутри функции createEventChannel. Сама по себе шина там достаточно типовая, что-то невероятное придумать сложно, однако код всё равно достаточно занятный, полный код можно найти в этом гисте

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #web #javascript #theory #code

Pattern matching

Pattern matching — это крутой концепт, который позволяет делать что либо в зависимости от совпадения с тем или иным шаблоном

В качестве шаблона может выступать какая-то константа или предикат

Самой примитивной реализацией концепта в JavaScript можно считать объекты или конструкцию switch-case:

const statusIcon = {
  warning: <WarningIcon />,
  success: <SuccessIcon />,
  error: <ErrorIcon />,
  loading: <Spinner />
}

const status = "error"
const matched = statusIcon[status]

Примерно то же самое можно реализовать и со switch-case, но всё это не так интересно

Есть такая библиотечка — ts-pattern. Она же позволяет отойти от примитивных примеров и использовать полноценный pattern matching, включая анализ вложенных структур и более сложные условия

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

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

Сам по себе концепт невероятно полезен для упрощения кода. Такой код проще читать, изменять и поддерживать. А в совокупности с ts-pattern, решение будет ещё и типобезопасно, что также неоспоримый плюс

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #web #javascript #theory #code

Порталы в React

Сталкивались когда-нибудь с проблемой, когда нужно рендерить элемент за пределами текущей DOM-иерархии?

Например, модальные окна, которые не должны быть вложены в основное дерево из-за проблем с позиционированием или всплывающие подсказки, которые всегда должны быть на переднем плане

Для таких задач React предлагает решение — порталы

В документации реакта приведён такой код:

import { createPortal } from 'react-dom';

<div>
  <p>Текст расположен в родительском диве</p>
  {createPortal(
    <p>Текст расположен в document.body </p>,
    document.body
  )}
</div>

Работает этот код проще простого: элемент, переданный в функцию createPortal, будет маунтиться реактом не в родительский див, а в document.body. Работать это будет с деревом любой вложенности

Такой код будет работать, но он не очень удобен, поэтому многие компонентные библиотеки максимально упрощают порталы для разработчиков и делают подобные компоненты — они есть в Chakra UI, Material UI, Semantic UI и других либах

Но, на самом деле, там нет ничего сложного

Если максимально упростить, то можно прийти к такому варианту:

const Portal = ({ children }: PropsWithChildren) => {
  const [container] = useState(() => document.createElement('div'));

  useLayoutEffect(() => {
    document.body.appendChild(container);
    return () => {
      document.body.removeChild(container);
    };
  }, [container]);

  return createPortal(children, container);
}

// ... 

<Portal>
  <p>Текст внутри портала</p>
</Portal>

Тут стоит уточнить две детали:

1. Мы создаём новый div внутри useState, чтобы проще было контролировать портал
Если мы будем рендерить контент сразу в document.body, то можно словить много проблем со стилями и отслеживанием самого портала

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

Как альтернатива, можно обойтись и рефом

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

useLayoutEffect используется вместо useEffect, чтобы обрабатывать портал без лишних мерцаний и более плавно

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

Да и всё. Тут компонент на 10 строчек буквально, ничего сверхъестественного. Если вам нужны порталы, то задумайтесь — скорее всего вам хватит такой простой реализации

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #web #javascript #theory #code