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

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

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

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

Составные компоненты

Есть такой паттерн для реакта, который называется Compound Components. Это можно перевести как "составные компоненты"

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

То есть мы можем заранее объединить компоненты каким-то контекстом и переиспользовать их, например, через общее пространство имён, в качестве которого чаще всего выступает родительский компонент

Запутались в словах? Лучше посмотреть в коде:

Вот пример прям из доки Ant Design:

import { Layout } from 'antd';

<Layout>
    <Layout.Header>Header</Layout.Header>
    <Layout.Content>Content</Layout.Content>
    <Layout.Footer>Footer</Layout.Footer>
</Layout>

Обратили внимание, как компоненты Header, Content и Footer мы получаем напрямую из компонента Layout? Это и есть пример паттерна Compound Components. Компоненты связаны, а используются они из общего пространства — компонента Layout

Зачем же так сделали? Тут преследуется три цели:
1. Явно показать на уровне нейминга, что использовать Layout.Footer вне Layout не нужно
2. Расшарить общий контекст между всеми компонентами Layout
3. Корректно стилизовать части Layout в зависимости от значения внутри общего контекста

С неймингом и стилями, думаю, всё предельно ясно. Но что насчёт контекста? На самом деле, Layout под собой содержит ещё и LayoutContext, который содержит в себе состояние компонента Sider и распространяет его на все дочерние компоненты. Схематически это выглядит примерно так:

InternalLayout  
└ LayoutContext <-- инициализируем контекст
   ├ Header
   ├ Content <-- а в этих компонентах получаем его значение
   ├ Footer
   └ Sider

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

С точки зрения типов всё тоже не сложно. Тот же Ant Design делает так:

import InternalLayout, { Content, Footer, Header } from './layout';
import Sider from './Sider';

// получаем тип базового layout компонента
type InternalLayoutType = typeof InternalLayout;

// создаём тип, который определит какие компоненты мы вложим в layout
type CompoundedComponent = InternalLayoutType & {
  Header: typeof Header;
  Footer: typeof Footer;
  Content: typeof Content;
  Sider: typeof Sider;
};

// нагло переприсваиваем тип
const Layout = InternalLayout as CompoundedComponent;

// нагло биндим нужные компоненты
Layout.Header = Header;
Layout.Footer = Footer;
Layout.Content = Content;
Layout.Sider = Sider;

// не менее нагло экспортируем как public-api
export default Layout;

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

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

Tree Shaking

Сам по себе Tree Shaking — это метод оптимизации кода, который позволяет автоматически удалять неиспользуемый код при сборке приложения

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

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

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

// зависящий от рантайма импорт
var my_lib;
if (Math.random()) {
    my_lib = require('foo');
} else {
    my_lib = require('bar');
}

// и экспорт
if (Math.random()) {
    exports.baz = ···;
}

Код выше абсолютно валиден

ES6 же предложил статическую систему модулей, благодаря чему Tree Shaking и стал в целом возможен

В примере с прикреплённого видоса мы видим, как в конечный бандл из файла math.js попадает только функция multiply. Происходит это как раз потому что sum() не используется в коде нашей программы index.js

Настроить всё очень просто, например, с тем же Vite — он поддерживает Tree Shaking из коробки при сборке в прод режиме ( обычно это vite build )

Однако, стоит помнить, что не весь код и библиотеки поддерживают Tree Shaking. "Шейкаться" будет только тот код, что использует ES6 модули

Проанализировать сборку через Vite можно с помощью плагина rollup-plugin-visualizer — он покажет, какие модули включены в финальную сборку, и сколько они весят

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

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

Ещё один пример

Бывает такое, что нужно встроить в строку значение, которое может быть пустым. Обычно пишутся доп. проверки:

const order = {
  city: "Москва" // представим, что возможно undefined или null
}

const { city } = order

// могут писать что-то типа такой проверки
city ? `Ваш город: ${city}` : null

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

type SubstitutionPrimitive = string | number | boolean | undefined | null;

const isNullOrUndefined = (value: SubstitutionPrimitive): value is undefined | null => {
  return value === undefined || value === null;
};

const safePaste = (strings: TemplateStringsArray, ...substitutions: SubstitutionPrimitive[]) => {
  let result = strings[0];

  for (let index = 0; index < substitutions.length; index++) {
    const value = substitutions[index];

    if (isNullOrUndefined(value)) return null;

    result += value + strings[index + 1];
  }

  return result;
};

Просто вернем null вместо строки, если какое либо из значений в подстановках null или undefined. Вот так это будет вызываться:

const apple = {
  name: 'Яблоко',
};
const orange = {};

safePaste`Товар: "${apple?.name}"`;
// Товар: "Яблоко"

safePaste`Товар: "${orange?.name}"`;
// null

Ну типа костыль. А вроде и нет. Просто ещё один пример посмотреть как это можно применить

@prog_way_blog — чат — #javascript #code

А, кстати, почему "не всегда"

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

В таких случаях соединение организуется через TURN сервер и WebRTC становится не p2p, а уже клиент-сервер-клиент способом коммуникации

TURN — Traversal Using Relay NAT — это протокол, который позволяет узлу за NAT или брандмауэром получать входящие данные через TCP или UDP соединения

Ну, вроде выговорился

Вот вам ещё визуализация всего, что я пытался описать текстом