Гайд по микрофронтендам на single-spa, или Как уже наконец-то уйти от монолита во фронтенде

Достаточно хорошая статья от Самокат про переход от монолита на ангуляре к микрофронтендам на VueJS с использование single spa (фреймворк для микрофронтендов). Реально интересная статья, показывающая на простом примере, как построить простое приложение на микрофронтендах

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

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

https://habr.com/ru/companies/samokat_tech/articles/766978/

#development #javascript #microfrontends #vue #singleSpa

Eslint: Deprecation of formatting rules

Eslint анонсировал deprecate правил и функционала, связанного с форматированием кода. В целом, давно пора, т.к. эту нишу занял Prettier и в последние годы почти никто (хотя у меня есть такие знакомые) не ожидает, что eslint будет что-то форматировать. В плагине Prettier даже есть конфиг, который отключает все правила форматирирования eslint, чтобы не было конфликтов с Prettier

В самом Eslint отказ объясняют следующими причинами:
- При разработке таких правил, нужно постоянно помнить о том, что они могут конфликтовать друг с другом
- Большие ожидания от этих правил, которые сложно оправдать
- Сложность разработки (сложно учесть все нюансы форматирования)
- Чем больше времени тратится на поддержку этих правил, тем меньше времени уделяется важному функционалу
- Отсутствие интереса у сообщества

Лично я давно использую связку eslint + eslint-plugin-prettier. Плагин запускает prettier вместе с eslint, что позволяет объединить 2 инструмента в одном, что убирает потребность в настройке отдельного запуска prettier в CI, пре-коммит хуках и тп.

https://eslint.org/blog/2023/10/deprecating-formatting-rules/

#development #javascript #eslint

Дайджест за 2023-11-20 - 2023-11-21

------

Статей на прошлой неделе было мало т.к. готовился к выступлению на митапе. Очень порадовало, что часть читателей канала пришли на митап - был рад вас увидеть и получить от вас фидбек 🧡

На этой неделе вхожу в привычный ритм - ссылка на что-то интересное будет каждое утро

------

Гайд по микрофронтендам на single-spa, или Как уже наконец-то уйти от монолита во фронтенде
Достаточно хорошая статья от Самокат про переход от монолита на ангуляре к микрофронтендам на VueJS с использование single spa (фреймворк для микрофронтендов). Реально интересная статья, показывающая на простом примере, как построить простое приложение на микрофронтендах

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

Eslint: Deprecation of formatting rules
Eslint анонсировал deprecate правил и функционала, связанного с форматированием кода. В целом, давно пора, т.к. эту нишу занял Prettier и в последние годы почти никто (хотя у меня есть такие знакомые) не ожидает, что eslint будет что-то форматировать. В плагине Prettier даже есть конфиг, который отключает все правила форматирирования eslint, чтобы не было конфликтов с Prettier


——————————————

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

Announcing TypeScript 5.3

Команда Typescript анонсировала релиз 5.3. Основные изменения, за которые зацепился мой глаз - оптимизация перформанса и размера и улучшение уточнения типов

Начну с уточнения типов: завезли корректное уточнение типов для паттерна switch (true)

function f(x: unknown) { 
 switch (true) { 
  case typeof x === "string": 
   // x - строка
   console.log(x.toUpperCase()); // нет break!
  case Array.isArray(x): 
   // 'x' - строка и массив
   console.log(x.length);
  default: 
   // а здесь x - unknown
 } 
}

Также улучшили уточнение проверки типов при сравнении с булами

interface A { 
 a: string; 
} 
interface B { 
 b: string; 
} 

type MyType = A | B; 

function isA(x: MyType): x is A { return "a" in x; } 

function someFn(x: MyType) { 
 if (isA(x) === true) { 
  console.log(x.a); // TS больше не ругается на эту строчку
 } 
}

Также улучшили работу instanceof. В JS есть возможность управлять работой оператора через Symbol hasInstance, но раньше typescript это не обрабатывал. Теперь обрабатывает.

class IAmUndefined { 
 static [Symbol.hasInstance](testedValue) { 
  return testedValue === undefined; 
 } 
} 

console.log(undefined instanceof IAmUndefined); // true

По поводу оптимизаций: typescript теперь избегает парсинга JSDoc - это ускоряет работу компилятора. Поведение можно включить обратно через опции TS. Также оптимизировали работу юнионов.

Еще из интересного - TS экспортировал 2 файла - typescript.js и tsserverlibrary.js с немного разным API, что усложняло использование TS. В итоге эти 2 файла объединили, что уменьшило итоговый размер пакета на 20%.

https://devblogs.microsoft.com/typescript/announcing-typescript-5-3/

#development #javascript #typescript #releaseNotes

Promises Training

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

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

https://github.com/henriqueinonhe/promises-training

#development #javascript #Promise #recommended #tutorial

Using the OpenAI platform to analyse automated test failures

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

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

Итого, репортер видит ошибку -> идет на expressjs сервер за информацией -> expressjs идет в openai -> пользователь вместо непонятной ошибки видит предложения от gpt о том, что случилось и как это исправить

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

https://labs.pineview.io/using-openai-platform-to-analyse-automated-test-failures/

#development #javascript #chatgpt #autotests

Moving back to React

Сайт daily.dev переходит с Preact на React. Долгое время команда писала на Next.js + Preact. Не смотря на то, что Preact поддерживает основные фичи React, команда столкнулась с проблемами:
- Медленный Hot Reload
- Медленная работа сборки в dev-режиме (включая фризы вкладки)

Этих проблем нет при использовании Next + React, поэтому было решено переходить на react.

Плюсы от потенциального перехода на React:
- React совместим с текущим Next.js и со всеми будущими фичами
- Меньше возни с конфигами
- Меньше зависимостей
- React более стабилен и в нем больше уверенности. Preact же старается быть как React, но также тащит фичи из других миров

Минусы:
- Размер бандла увеличится
- Нужно поменять много кода

Размер бандла
Увеличение размера бандла оказалось ожидаемым - ровно на разницу между React и Preact. Влияние можно минимизировать, выделив react в отдельный чанк с отдельным кешированием. Также, во время замеров, были обнаружены возможности для оптимизации размера бандла в приложении, решение которых позволит еще сильнее минимизировать влияние перехода на React на пользователей

План миграции
Команда решила сделать миграцию в рамках внутреннего хакатона, который решили проводить во время общего недельного сбора в Польше (команда разработки сайта - распределенная). Перед началом хакатона определили несколько основных зон для изменений:
- Нужно убрать и заменить все что связано с Preact (зависимости и все такое)
- Все автотесты должны быть зелеными (но потребуется поднять версию Jest)

Т.к. Preact поддерживает подмножество функционала React, то переезд на React не должен быть в целом сложным. Но при этом проблемы, естественно, возникнут. Эти проблемы решили поделить на 2 категории: ошибки и предупреждения (errors and warnings). Предупреждения - это все то, что не влияет на работу приложения или на пользователя. Ошибки же - все, что может привести к неправильной работе сайта (в том числе утечки памяти)

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

Итоги
После перехода на React исчезли проблемы с DX, которые очень сильно замедляли разработку, а также открылась возможность использовать свежую версии библиотек и Next.js

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

https://daily.dev/blog/moving-back-to-react

#development #javascript #react #migration

Microservices aren't the problem. Incompetent people are

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

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

Статья начинается с того, что нет проблемы в конкретной технологии, будь то микросервисы или Kafka или еще что-то. С технологиями все хорошо, это с инженерами, которые применяют инструменты не к месту, все плохо. Вся наша индустрия построена на принципе hype-driven development. Мы постоянно меняем подходы, технологии и инструменты, но не отказываемся от старых привычек. Это как всю жизнь работать с молотком, потом получить отвертку, но все равно работать ей как молотком

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

Инженеры считают себя умными, но, как правило, большинство из них такими не являются. Автор называет это smart-ass complex. Если переводить грубо, то "комплекс умной задницы", хотя мне в последнее время для обозначения этой проблемы нравится классика - "Горе от ума".

smart-ass инженер:
- Переусложняет решения. Там где можно было сделать что-то в лоб, умный инженер сделает микросервисную масштабируемую систему с наиболее подходящим тех. стеком
- Использует разные имена для одной концепции, говоря, что в разных контекстах названия должны быть разные (например фасад, адаптер, мост и тд для обозначения врапера)
- Борется с несуществующими проблемами. Наиболее яркий пример - взять практики гугла, имея на сервис менее 1 RPS, зато получив запас прочности при масштабировании на десятилетия вперед
- И так далее

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

Как быть компетентным? Автор предлагает свое видение принципов, которым следуют компетентные инженеры:
- Применять SOLID на разных уровнях: код, сервисы, команды, организация (в оригинале расписано очень подробно, но я переводить не стал. Если вам интересно - окунитесь в оригинал)
- В чем отличие монолита от микросервиса? В коде приложения разнцы особой нет т.к. вся суть в том, что единственная разница - это механика коммуникации. В монолите мы просто вызываем нужную функцию, в микросервисе же используем сетевое взаимодействие для той же цели. Следует применять сервисную архитектуры. Т.е. писать такие сервисы, которые не микро, но и не монолит. Каждый сервис принадлежит конкретной команде, которая за него ответственна
- Думайте о Developer Experience
- KISS
- Откиньте подход "все или ничего". Не следует ультимативно следовать каким-то практикам т.к. в большинстве случаев это непрактично. Например, не случится ничего страшного, если вы добавите функционал в существующий микросервис сбоку, вместо написания нового. Написанный сбоку функционал всегда можно вынести позже.
- Ownership - у каждого сервиса есть свой owner и только он туда может вносить правки. Это позволяет быть уверенным что владелец знает все о том, как работает сервис и что он поддерживает его качество на высшем уровне.

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

https://nondv.wtf/blog/posts/microservices-arent-the-problem-incompetent-people-are.html

#development #microservices #architecture #softwareEngineering

Advent of TypeScript

Набор заданий type challenge для TypeScript, который будет открывать по одной задаче в день с 1-ого по 25-ого декабря и может послужить отличным поводом или дополнительно попрактиковаться, или изучить работу типов в языке.

Дайджест за 2023-11-27 - 2023-12-01

Announcing TypeScript 5.3
Команда Typescript анонсировала релиз 5.3. Основные изменения, за которые зацепился мой глаз - оптимизация перформанса и размера и улучшение уточнения типов

Начну с уточнения типов: завезли корректное уточнение типов для паттерна switch (true)

⭐Promises Training
Очень интересный репозиторий, который содержит в себе задачки по работе с Promise'ами. Они разделены на уровни сложности. К каждой задачке есть четкое описание, что нужно сделать и на все задачки написаны тесты. Если все тесты проходят - вы решили задачку правильно.

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

Using the OpenAI platform to analyse automated test failures
С появлением нейронок появляются все новые и новые интеграции в существующие инструменты. Некоторые идеи лежат прям на поверхности и вот, статья как раз об одной из них. Существует проблема, что ошибки от инструментов не очень информативные. Например, упал пайплайн в CI. Средний разработчик может зайти в упавшую джобу и ничего не понять и тогда ему приходится гуглить. Почему бы это не автоматизировать с помощью gpt нейронки?

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

Moving back to React
Сайт daily.dev переходит с Preact на React. Долгое время команда писала на Next.js + Preact. Не смотря на то, что Preact поддерживает основные фичи React, команда столкнулась с проблемами:
- Медленный Hot Reload
- Медленная работа сборки в dev-режиме (включая фризы вкладки)

Microservices aren't the problem. Incompetent people are
Какое-то время назад все только и говорили о микросервисах. Затем, стали говорить, что микросервисы не нужны - слишком сложно и много накладных расходов. Дмитрий Нон возвращается к этой теме, но рассматривает её под другим углом - проблема не в подходе микросервисах, а в недостаточной компетенции разработчиков.

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

——————————————

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

67 Weird Debugging Tricks Your Browser Doesn't Want You to Know

Список из 67 трюков для дебага кода в браузере. Причем, это не те простые трюки, которые часто описывают в туториалах, здесь описаны прям хорошие приёмы. Описаны применение API-браузеров и продвинутой использование breakpoint'ов с условием по выражению.


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

function test() {}
monitor(test);
test('lol', 'kek')
// в консоли будет function test called with arguments: lol, kek

Сталкивались ли вы с таким, что вам нужно понять, кто меняет какое-то css свойство элемента? Т.к. css-стили - каскадные, это может быть сложно сделать. Но ведь можно повесить breakpoint, который срабатывает на JS выражении, которое будет проверять итоговые стили. Например, мы хотим остановить исполнение кода, когда backbround-color станет красным:

window.getComputedStyle(document.body).backgroundColor === "rgb(255,0,0)"

Или другой кейс. У вас есть какое-то поведение на элементе при наведении на него и оно реализовано через JS, а не css :hover. Как быть? Автор предлагает следующий хак: вызвать debugger в setTimeout, затем навести мышку на нужный элемент и дождаться вызова debugger. Работа браузера остановиться и можно дебажить элемент сколько угодно

setTimeout(() => { debugger; }, 5000)

В общем, очень крутой список. Рекомендую к ознакомлению

https://alan.norbauer.com/articles/browser-debugging-tricks

#development #googleChrome #debug #recommended #javascript

Node.js CLI Apps Best Practices

Список бест-практисов для CLI приложения на node.js. Разделены на группы:
- Опыт использования
- Публикация
- Встраиваемость (Interoperability)
- Доступность
- Тестирования
- Работа с ошибками
- Разработка
- Аналитика
- Версионирование

https://github.com/lirantal/nodejs-cli-apps-best-practices

#development #nodejs #cli #recommended

Secure Code Review Tips to Defend Against Vulnerable Node.js Code

Короткая статья про обеспечение безопасности в node.js приложениях. Данная статья, я так понял, является первой в цикле и рассказывает о небезопасных паттернах кода (на самом деле паттерн 1, но почему-то разбит на 4 части).

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

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

const userInput = req.query.input;
const command = `echo ${userInput}`;
exec(command, (error, stdout, stderr) => {
  // Handle the command execution
});

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

https://www.nodejs-security.com/blog/secure-code-review-tips-to-defend-against-vulnerable-nodejs-code

#development #nodejs #security

Event Loop в деталях

Неплохая статья, объясняющая для новичков, как работает Event Loop в Javascript. Статья делает это не совсем точно (собственно один из комментариев на хабре посвящен именно этому аспекту статьи), но достаточно доступно и понятно для тех, кто не знает как работает Event Loop. В целом, как начальная статья для джунов вполне ок.


https://habr.com/ru/articles/762618/

#development #javascript #eventLoop #tutorial

Leading Successful Product Teams

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

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

- Избегайте встреч и созвонов. Вместо этого используйте асинхронные коммуникации (чаты, рабочие инструменты и тд)
- Предоставьте по-крайней мере 3 дня фокусированный работы в неделю для дизайнеров и разработчиков.
- Доверяйте команде самой принимать решения. Ваша задача, чтобы команда понимала, что делает, устранять препятствия и защищать от внешних воздействий.
- Будьте открытыми. Команда должна создавать продукт, не закрываясь от других команд и людей. Это неизбежно повысит качество создаваемого продукта
- Держите количество процессных активностей (дейли, груминги и тд) в таком количестве, чтобы это уже помогало работать, но еще не мешало
- Не проводите синки по задачам на всю команду ежедневно, достаточно собраться раз в неделю, замотивировать команду и подсветить блокеры
- Используйте как можно меньше инструментов для реализации задачи
- Автоматизируйте все, что возможно автоматизировать. Команда должна проводить ценное время с коллегами, пользователями, а не заниматься рутиной
- Заботьтесь о своих пользователях.
- Большинство актов общения и совместной работы должны быть асинхронными.
- Позвольте участникам команды решать проблемы сообща, если это полезно. Но не забудьте задокументировать все принятые решения.
- Предоставляйте еженедельные отчеты для всех заинтересованных о прогрессе в работе
- Создайте публичный родмап
- Сфокусируйтесь на регулярных итерациях вместо ярких запусков
- Не бойтесь выбрасывать сделанную работу
- Поставленное пользователю лучше, чем идеальное, но не поставленное
- Будьте добрыми

https://arie.ls/2023/leading-successful-product-teams/

#managment #team

Дайджест за 2023-12-04- 2023-12-08

⭐67 Weird Debugging Tricks Your Browser Doesn't Want You to Know
Список из 67 трюков для дебага кода в браузере. Причем, это не те простые трюки, которые часто описывают в туториалах, здесь описаны прям хорошие приёмы. Описаны применение API-браузеров и продвинутой использование breakpoint'ов с условием по выражению.


⭐Node.js CLI Apps Best Practices
Список бест-практисов для CLI приложения на node.js. Разделены на группы:
- Опыт использования
- Публикация

Secure Code Review Tips to Defend Against Vulnerable Node.js Code
Короткая статья про обеспечение безопасности в node.js приложениях. Данная статья, я так понял, является первой в цикле и рассказывает о небезопасных паттернах кода (на самом деле паттерн 1, но почему-то разбит на 4 части).

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

Event Loop в деталях
Неплохая статья, объясняющая для новичков, как работает Event Loop в Javascript. Статья делает это не совсем точно (собственно один из комментариев на хабре посвящен именно этому аспекту статьи), но достаточно доступно и понятно для тех, кто не знает как работает Event Loop. В целом, как начальная статья для джунов вполне ок.



Leading Successful Product Teams
Набор правил успешной команды от лида команд дизайн-систем. Дизайн-системы отличаются от традиционных продуктовых команд, но, тем не менее, имеют много пересечений.

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

——————————————

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

Web Components Eliminate JavaScript Framework Lock-in

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

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

Автор делает TodoList с использованием React, Vue, Svelte и Solid. Все созданные компоненты оборачиваются в кастомные элементы и используют друг друга как кастомные элементы. При этом автор также обращает внимание на гибкость веб-компонентов, организации взаимодействия и хранении стейта.

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

https://jakelazaroff.com/words/web-components-eliminate-javascript-framework-lock-in/

#development #javascript #webcomponents

Track Frontend JavaScript exceptions with Playwright fixtures

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

В чем проблема: браузерные автотесты весьма полезны т.к. позволяют быть уверенными, что система работает end-to-end или близка к этому. Но тесты проверяют только конкретный функционал. А бывает так, что конкретный функционал работает, но что-то другое падает и в консоли видна ошибка. При ручном тестировании это заметно, но автотесты это не отлавливают. Но автотесты можно научить проверять глобальные ошибки. Именно этим автор и занимается в статье с помощью Playwright

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

test("Checkly blog lazy loading", async ({ page }) => {
  // set up a new Array to collect thrown errors
  const errors: Array<Error> = []

  // listen to exceptions during the test sessions
  page.on("pageerror", (error) => {
    errors.push(error)
  })
  
  // All your test code…
  // …

  // assert that there haven’t been any errors
  expect(errors).toHaveLength(0)
})

Но писать такое в каждом тесте непродуктивно. У Playwright есть API для расширения метода test - фикстуры. Фикстуры это такие объекты или функции, которые доступны в тесте и они создаются новые для каждого теста.

const myTest = test.extend<{
 testUser: { name: String }
 loggedInPage: Page
}>({
  testUser: {
    name: "Jenny Fish",
  },
  async loggedInPage({ page }, use) {
    await page.goto("/login")
    /* code */
    await use(page)
    // clean up steps after the test
  },
})

// Теперь testUser и loggedInPage доступы в тесте
myTest("Your custom Playwright setup", async ({ testUser, loggedInPage }) => {
  // …
})

Фикстуры устроены так, что у них есть 3 этапа:
- подготовка
- передача в тест - await use(fixture) передает фикстуру в тест и дожидается завершения теста
- действия после завершения теста

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

// extend the test object and assign it to a new `myTest` variable
const myTest = test.extend<{ page: void }>({
  // override and use Playwright’s base `page` fixture 
  page: async ({ page }, use) => {
    const errors: Array<Error> = []

    page.addListener("pageerror", (error) => {
      errors.push(error)
    })

    // pass the `page` object to tests using it
    await use(page)

    expect(errors).toHaveLength(0)
  },
})

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

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

https://www.checklyhq.com/blog/track-frontend-javascript-exceptions-with-playwright/

#development #javascript #playwright #testing

console ninja: console log output right next to your code

Интересный тулинг по типу wallaby и quokka, который связывает код в IDE и консоль в приложении. Т.е. например, вы поставили console.log(myVariable) и вывод консоли отобразится у вас прямо в IDE. Кроме этого инструмент умеет связывать ошибки с кодом, создавать лог-поинты (это как брекпоинты, только вместо остановки мы просим вывести значение переменной в лог) и еще всякое.

Есть платная и бесплатная версии. Посмотрите, возможно вам понравится.

https://console-ninja.com

#development #javascript #tool

Keep that cursor still!

Веб-разработчики делятся на 2 типа - познавшие боль от работы с курсором в input'ах и тех, кому это только предстоит.

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

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

В целом, это поведение мы можем видеть в двух кейсах:
- Преобразование значения в onChange
- Асинхронный обработчик. Здесь не обойтись без примера: в инпуте было значение авг, пользователь вводит б между а и в. Но у нас так устроена архитектура, что значение в инпут ставится из какого-нибудь redux, а туда новое значение попадает через несколько тиков в эвент-лупе. С точки зрения браузера это означает, что мы сначала поменяли значение абвг на авг, а через пару тиков на абвг. Оба раза курсор улетел в конец

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

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

export default function App() {
 const position = useRef({
  beforeStart: 0,
  beforeEnd: 0
 });

 const [val, setVal] = useState("hello");
 const inputRef = useRef<HTMLInputElement>(null);
 useLayoutEffect(() => {
  inputRef.current.setSelectionRange(
   position.current.beforeStart,
   position.current.beforeEnd
  )
 }, [val]);

 const onChange = (e: ChangeEvent<HTMLInputElement>) => {
  const beforeStart = e.target.selectionStart;
  const beforeEnd = e.target.selectionEnd;
  position.current = {
   beforeStart,
   beforeEnd
  };

  setVal(e.currentTarget.value.toUpperCase());
 };
 return (
  <input ref={inputRef} value={val} onChange={onChange} />
 );
}

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

export default function App() {
  const position = useRef({
    beforeStart: 0,
    beforeEnd: 0
  });

  const [val, setVal] = useState("hello");

  const inputRef = useRef<HTMLInputElement>(null);

  const onChange = (e: ChangeEvent<HTMLInputElement>) => {
    const beforeStart = e.target.selectionStart;
    const beforeEnd = e.target.selectionEnd;

    position.current = {
      beforeStart,
      beforeEnd
    };

    flushSync(() => {
      setVal(e.currentTarget.value.toUpperCase());
    });

    inputRef.current.setSelectionRange(beforeStart, beforeEnd);
  };

  return <input ref={inputRef} onChange={onChange} value={val} />
}

В общем, очень крутая статья, в ней крутые sandbox'ы с примерами проблемы и примерами решений, в которой очень подробно разбирается почему происходит эта проблема (включая разбор внутренностей React). Рекомендую к прочтению

https://giacomocerquone.com/keep-input-cursor-still/

#development #javascript #react #input #cursor #recommended