📖 Мигрируем БД в продакшене без даунтайма

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

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

Например, если требуется удалить поле из БД, нужно выполнять деплой в 2 захода:
1. Удаляем весь код, работающий с этим столбцом — деплоим
2. Удаляем столбец и снова — деплоим

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

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

https://habr.com/ru/post/664028/

#fridayreading #architecture

​​📖 Не трогайте разработчиков. Отстаньте. Просто не беспокойте

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

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

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

Особенности процесса
- Кажется что производительность команды снизится, но на самом деле этого не должно произойти — ведь остальные будут сосредоточены на решении задач и будут более продуктивны
- Дежурят только желающие, никого не заставляют
- Для обучения можно назначать двух дежурных, один — опытный, второй — новичок. Опытный ничего не делает руками, кроме ЧП ситуаций, так происходит обучение новичка.
- Может быть несколько дежурных: кто-то отвечает за релизы, кто-то за поддержку
- У дежурного не должно быть релизных задач, если у него появляется свободное время:
- Он дописывает документацию
- Работает над техническим долгом
- Автоматизирует бизнес процессы
- Фиксит баги

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

https://habr.com/ru/company/gazprombank/blog/678000/

#fridayreading #processes

​​📖 Avoid These Common Pitfalls Of React useState

Статья описывает самые популярные ошибки при использовании useState в Реакте:
- Избыточное состояние (Redundant State)
- Дублирующее состояние (Duplicate State)
- Обновление состояния через useEffect (Updating State Via useEffect)
- Подписка на изменения состояния через useEffect (Listening To State Changes Via useEffect)
- Конфликтующие состояния (Contradicting State)
- Состояние с глубокой вложенностью (Deeply Nested State)

Среди описанные проблем нашёл практически кусок своего кода, связанный с асинхронными запросами — пример как не надо делать прикреплён. Чтобы не совершать таких ошибок, нужно вспомнить о некоторых рекомендациях, когда лучше использовать useReducer:
- Для управления объектом, лучше использовать useReducer
- Для управления состояниями, зависящими друг от друга, лучше использовать useReducer — как раз этот случай и описывается в статье

#react #frontend #fridayreading

▶️ Интегрируем Яндекс Музыку в Visual Studio Code

3 года назад я начал писать расширение для Яндекс Музыки, за это время пришлось решить много интересных задач:

1️⃣ Создание библиотеки для Яндекс.Музыки
2️⃣ Создание OpenAPI схемы и обход CORS
3️⃣ Воспроизведение музыки с помощью Electron
4️⃣ Ну и собственно интеграция всего этого в VS Code

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

➡️ Интегрируем Яндекс Музыку в Visual Studio Code ⬅️

#yandexmusic #vscode #javascript #openapi

📖 React 18 — useTransition, useDeferredValue

React 18 вышел уже почти год назад, но только сейчас решил поискать наглядные примеры использования новых хуков useTransition и useDeferredValue и наткнулся на отличное видео “Новые хуки useTransition и useDeferredValue в React 18”. Оба хука работают благодаря конкурентному режиму, который позволяет прерывать рендеринг.

Пример

Допустим у нас есть поле поиска и очень длинный список заказов. При каждом изменении мы ре-рендерим список. Например, вы хотите купить новый айфон и вводите iphone в поле поиска, ре-рендеринг произойдёт 6 раз (для значений i, ip, iph ipho, iphon, iphone) — на каждое изменение. К тому же пока рендеринг не завершён — основной поток приложения заблокирован и пользователь не может взаимодействовать с приложением, из-за чего страдает UX. Однако это очень не оптимально, ведь когда мы вводим каждый новый символ, предыдущие результаты поиска для нас больше неактуальны и было бы логичнее приостановить рендеринг и запустить новый.

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

Вероятно вы не замечаете проблем с производительностью на своём Macbook Pro M2, но далеко не у всех пользователей такие же шустрые устройства. Но вы можете стать ближе к народу и включить эмуляцию медленной производительности в DevTools в Performance ⇒ CPU ⇒ 6x slowdown.

useDeferredValue не содержит конкретного таймаута, для обновления значения. Реакт сам решит, когда значение будет обновлено в зависимости от от того, насколько Реакт в данный момент занят другими вычислениями. Принцип работы хука довольно простой, когда useDeferredValue получает новое значение — под капотом запускается ре-рендер, если этот ре-рендер не прерван — UI обновляется. Но если хук получил ещё одно новое значение — то старое состояние устарело, вычисление виртуального дома прерывается и процесс начинается заново.

Принцип работы работы useTransition аналогичен — если startTransition запускается несколько раз — отрендерится лишь последний результат, а все предыдущие будут прерваны.

Оба хука взаимозаменяемы:
- Используйте useTransition, если у вас есть доступ к обновлению состояния
- Используйте useDeferredValue, например, если вам необходимо запустить обновление в ответ на изменение пропса.

Подход похож на debounce, но это не одно и то же. Когда мы используем debounce, рендер просто откладывается, но мы не можем его прервать, и UI всё равно может зависнуть через указанный таймаут.

Ещё по теме
- Основные изменения React 18
- useDeferredValue — How does deferring a value work under the hood?
- useTransition

#fridayreading #react #javascript #frontend

​​Контроль импортов с помощью import/no-restricted-paths

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

Пример 1️⃣
Допустим у нас есть:
- ui-kit — папка с базовыми компонентами
- rest-api — папка с сервисами для коммуникации с сервером
Очевидно, что содержимое rest-api не должно ничего знать о компонентах.

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

Решение ✅
Eslint предоставляет мощное правило import/no-restricted-paths, которое поможет описать зависимости между папками/модулями и запретить нежелательные импорты, описанные в примерах.

Если вы используете CRA вам достаточно добавить следующий код в package.json в поле eslintConfig. В примере ниже мы запрещаем любые импорты из папки domains в папку components из примера 2.

"rules": {
  "import/no-restricted-paths": [
    "error",
    {
      "zones": [
        {
          "target": "./src/components",
          "from": "./src/domains"
        }
      ]
    }
  ]
},
"settings": {
  "import/resolver": {
    "node": {
      "extensions": [
        ".js",
        ".jsx"
      ]
    }
  }
} 

Если вы используете TypeScript, дополнительно нужно установить пакет eslint-import-resolver-typescript и изменить поле settings следующим образом:

"settings": {
    "import/resolver": {
      "typescript": {
        "project": "./tsconfig.json"
      }
    }
  } 

Подробнее можено почитать в статье Как правила линтинга влияют на архитектуру приложения

#linters #javascript #typescript #architecture

Martin Fowler Blog: Slack

Обычно, при планировании итерации, мы пытаемся забить команду работой под завязку. Например, высчитываем velocity из трех последних итераций и понимаем, что команда в среднем делала Х работы. Давайте запланируем на следующую итерацию Х работы. Получается даже не с потолка, а основываясь на данных.

Проблема этого подхода в том, что у команды не остается буфера для внезапных задач, рефакторингов, налаживания процессов. Вместо этого предлагается ввести Slack (наверное корректный перевод будет зазор, но я не уверен). Т.е. планировать заведомо меньше, чем обычно делает команда. Например, команда на протяжении последних N итераций делала 30 работы, но минимальное значение было 20 - давайте планировать итерации на 20, а все остальное - это зазор.

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

https://martinfowler.com/bliki/Slack.html

#managment #martinFowler #estimation #velocity #process

​​📖 Я наконец-то попробовал ChatGPT

Я не особо успеваю за трендами, поэтому попробовать ChatGPT дошли руки только сейчас.

Регистрировался по инструкции из статьи.

- Перед регистрацией почистил куки браузера
- В качестве VPN использовал VeePN-расширение для хрома
- Для регистрации использовал свой google аккаунт
- Пользовался сервисом OnlineSim для регистрации иностранного номера чтобы получить SMS код для регистрации
- Пополнил счёт на 50 рублей через СБП
- Пользовался Нидерландским номером для регистрации, который купил за $0.54
- Без VPN не могу зайти на сайт ChatGPT
- Переодически нужно перезагружать страницу

Я попросил его написать пост на основе текста, который вы прочитали выше и вот что получилось

#chatgpt #fridayreading

​​📖 Процесс ревью кода структурно порочен. Вот, как его исправить

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

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

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

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

Как решить?
- Обсудить план решения с более опытным коллегой, чтобы в дальнейшем пришлось меньше переделывать
- Произвести первое ревью, когда изменения готовы на 30-50%. Скорее всего ваш план не сработал на 100%, поэтому ваши видения с ревьюером снова разошлись, поэтому нужно снова провести ревью. Здесь необходимо смотреть на концепцию решения задачи и не придираться к небольшим ошибкам.
- Чтобы сократить время ожидания ревьера можно ввести роль дежурного по ревью. Как только появляется PR, ревьер сразу же приступает к ревью. В свободное время ревьюер занимается низкоприоритетными задачами: техническим долгом или неважными багами.

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

#fridayreading #codereview

​​🧮 Задача на знание this в JavaScript

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

Что будет выведено в консоль?

function foo() {
  const x = 10;

  return {
    x: 20,
    bar: () => console.log(this.x),
    baz() {
      console.log(this.x);
    },
  };
}

foo.x = 50;

const obj1 = foo();
obj1.bar(); // ?
obj1.baz(); // ?

const obj2 = foo.call({ x: 30 });
const x = obj2.bar;
x(); // ?
obj2.bar(); // ?
obj2.baz(); // ?

Необходимая теория для решения задачи
- this - контекст вызова функции. Если метод вызывается не на объекте, то this — глобальный объект window, иначе this указывает на объект, на котором был вызван метод.
- У стрелочной функции нет собственного this. Если внутри стрелочной функции идёт обращение к this, его значение, как и обычная переменная, берётся из внешнего лексического окружения.
- Если метод объекта присвоить переменной, и вызвать такую переменную-функцию, то контекст потеряется и this будет ссылаться на window. Но это не работает в случае стрелочной функции, так как у неё нет собственного this, поэтому и потерять она его не может.

Разбор задачи построчно
6. bar — стрелочная функция, this берётся из лексического окружения
7. baz — обычная функция, поэтому this будет ссылаться на возвращаемый объект
15. Так как функция foo вызывается не на объекте, то this в этом случае равен глобальному объекту — window.
16. Так как стрелочная функция берёт this из лексического окружения, то this = window. В консоль будет выведен undefined, потому что на window не определено свойство x.
17. Функция baz реализована с помощью обычной функции, поэтому в данном случае this ссылается на сам объект. В консоль будет выведено 20.
19. Здесь явно указывается контекст вызова функции — объект { x: 30 }
20-21. Так как метод bar реализован с помощью стрелочной функции, то контекст в данном случае не теряется. Используется контекст из лексического окружения — { x: 30 }. В консоль будет выведено 30.
22. Вызывается тот же метод bar, логика точно такая же. В консоль будет выведено 30.
23. Явное указание контекста при вызову функции foo никак не влияет на функцию baz, так как метод вызывается на объекте, и контекстом будет являться данный объект. В консоль будет выведено 20.

Ответ ⬇️
undefined
20
30
30
20

Теория по теме
- Повторяем стрелочные функции
- Конструктор, оператор "new"
- Методы объекта, "this"
- Привязка контекста к функции

#javascript #interview

📖 Выравнивание последнего элемента по правому краю с помощью flexbox

Сегодня хочу порекомендовать короткую, но очень полезную статью о флексбоксах How to Align Last Flex Item to Right.

Довольно часто необходимо сверстать UI, в котором все элементы выровнены слева, и только один необходимо выравнять по правому краю.

Раньше я делал так:
- Создавал 2 div’а-обёртки
- Всё что должно быть слева клал в левый div
- Элемент, который должен быть справа, клал в правый div
- К родительскому элементу применял justify-content: space-between

Это решение всегда работает, но можно обойтись и без div’ов-обёрток. Всё, что нужно сделать — применить margin-left: auto к элементу, который должен располагаться справа.

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

HTML разметка:

<div class="flex-container">
  <div class="flex-item">Первый элемент</div>
  <div class="flex-item">Второй элемент</div>
  <div class="flex-item align-right">Последний элемент</div>
</div>

CSS код:

.flex-container {
    display: flex;
}

.flex-item {
    border: 1px solid black;
}

.align-right {
    margin-left: auto;
}

💡 Пояснение
Дело в том, что всё свободное пространство будет распределено между auto-маржинами. Подробнее можно почитать в спеке флексбоксов Aligning with auto margins.

#html #css #flexbox #fridayreading

​​🧮 Задача на знание замыканий в JavaScript

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

/** 
* Нужно написать функцию, которая принимает число N и возвращает функцию,
* вызов которой первые N раз возвращает 'yes', а потом – 'no'.
*/
function canGetCount(n) {
    // code here
}

const getOne = canGetCount(2);
 
getOne()  === 'yes'
getOne()  === 'yes'
getOne()  === 'no'

#javascript #interview

https://github.com/localtunnel/localtunnel

npx localtunnel --port 3000

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

🎬 Backend-Driven UI

Сегодня посоветую доклад с HolyJS — Виталий Полещук, Стёпа Михайлюк — Server-driven UI в вебе. Не пиши, а описывай свой фронтeнд

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

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

- header
- select
- checkbox
- …

клиент проходится по этому массиву и рендерит соответствующий UI компонент. Таким образом реализация компонентов находится на фронте, а их расположение и взаимодействие на бэке.

👍 Основные преимущества Backend Driven UI

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

Ещё по теме:
- Яндекс выпускает DivKit — фреймворк для server-driven UI с открытым кодом

#fridayreading #frontend #architecture

🍎 Хочу поделиться Apple Shortcuts для добавления в инбокс Notion

Хочу поделиться с вами отличной находкой, связанной с Apple Shortcuts. Год назад я упоминал, что с помощью Apple Shortcuts можно с легкостью добавлять записи в базу ноутшена, например, я использую её для добавления записей в мой инбокс.

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

Чтобы настроить это, вам нужно сделать всего лишь несколько шагов (скриншот в комментариях):

1. В блоке "Text" вставьте идентификатор вашей базы вместо "<your database id>".
2. В блоке "Get contents of" вставьте ваш секретный токен интеграции вместо "<your secret token>".
3. Вместо "Name" укажите название вашего поля, если оно отличается.

Я подготовил два шаблона для добавления записей, чтобы вам было проще начать использовать это:

- Команда для добавления записи текстом
- Команда для добавления записи голосом

Инструкцию по настройке команды с нуля можно найти здесь.

Если будут вопросы — пишите, будем разбираться.

#notion #nocode #automation

📖 Неделя после пуска или Cooldown week

Как часто после очередного спринта вы чувствуете, что

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

Кроме того, вам в любом случае нужно время между релизами, чтобы

- подвести итог прошлого релиза
- запланировать следующий

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

“Неделя после пуска” — это не какой-то набор обязательных активностей, вы можете применять её в своей компании под ваши собственные нужды.

Такой подход используется в Basecamp и в Бюро Горбунова

- Basecamp — How we work — Cooldown
- Бюро Горбунова — Как оценивать доработки после запуска?

#processes #fridayreading #planning

​​❓Как восстановить удалённый коммит в Git?

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

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

Если ветки сильно отличаются, то иногда приходится делать git clean -fxd, чтобы удалить все ненужные артефакты. И тут я понял, что удалил все свои изменения.

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

git reflog

Нашёл в списке хэш моего коммита и перенёс из него все изменения в текущую ветку с помощью: git cherry-pick —no-commit <hash>

#git

📖 О бизнес процессах и авторитаризме

На майских праздниках я наконец-то дочитал книгу “Авторитарная Россия. Бегство от свободы, или Почему у нас не приживается демократия”.

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

💡 Мысль

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

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

То есть, государство тем или иным образом берёт все рычаги власти в свои руки и наводит порядок “жёсткой рукой”. Таким образом временно (опять же, в лучшем случае) происходит отклонение от демократии в сторону авторитаризма.

💼 Ассоциации с бизнес-процессами в компании

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

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

👀 Пример

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

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

P.S. Главное не слишком сильно закручивать гайки, иначе весь механизм разлетится вдребезги.

#processes #book #politics #fridayreading

📖 What developers need to know about Chrome's Memory and Energy Saver modes - Chrome Developers

В конце прошлого года в Google Chrome появились 2 новых режима

- Memory Saver (Экономия памяти)
- Energy Saver (Энергосбережение)

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

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

🔸 Energy Saver: Режим Energy Saver позволяет браузеру снизить частоту обновления экрана для экономии заряда батареи. Обычно, для большинства сайтов, не требуется внесение изменений, но если вы используете JavaScript-анимации, имейте в виду, что они могут замедлиться.

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

В данный момент нет никаких событий, которые будут запущены перед выгрузкой вкладки. Рекомендуются следующие способы сохранения состояния:

- Периодически, когда состояние изменяется
- Когда вы переходите на другую вкладку, по событию visibilitychange

document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    storeState();
  }
});

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

- Для этого можно открыть в адресной строке chrome://discards и для нужно вам вкладки использовать кнопку Urgent Discard.
- Инструменты автоматического тестирования пока не помогут вам протестировать эти режимы с помощью автотестов. Но вы можете использовать простую перезагрузку страницы, она почти полностью идентична выгрузке вкладки. Разница лишь в том, что при выгрузке вкладки, события beforeunload, pagehideи unload не будут вызваны.

Подробнее можно почитать в статье

#javascript #browser #frontend #fridayreading