Hello Bun: How Sveld now deploys 2x faster on GitHub and Render

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

Какие результаты:
- Сборка пакета в github-actions проходит в 2-3 раза быстрее
- Пакеты устанавливаются в 2-20 раз быстрее. При этом bun без кешей не сильно отстает от Yarn с кэшами.
- Юнит-тесты бегут в 2 раза быстрее
- В 2 раза ускорился деплой в Render (это платформа для деплоя статичных сайтов

https://render.com/blog/hello-bun-deploy-2x-faster-on-github-render

#development #javascript #bun #migration #svelte

The Front End Developer (Engineer) Handbook 2024

Невероятно огромный handbook про профессию фронтенд инженера в 2024 году. В хендбуке описано все - начиная от определения профессии, переходя через базовые знания (работы сети например) и заканчивая обзором современных инструментов и практик.

Рекомендую к просмотру

https://frontendmasters.com/guides/front-end-handbook/2024/

#development #frontend

HTML attributes vs DOM properties

Джейк Арчибальд написал хорошую статью про разницу между HTML Атрибутами и свойствами DOM-элемента. Я, честно говоря, никогда даже об этом не задумывался - работает и работает. В статье хорошо объясняется разница между ними, а также показываются подводные камни при работе с ними

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

const div = document.createElement('div');

div.setAttribute('foo', 'bar'); 
div.hello = 'world'; 

console.log(div.outerHTML); // '<div foo="bar"></div>'

const obj = { foo: 'bar' }
div.setAttribute('foo', obj); 
console.log(typeof div.getAttribute('foo')); // 'string'
console.log(div.getAttribute('foo')); // '[object Object]'

// <div id="test" HeLlO="world"></div>
const div = document.querySelector('#test'); console.log(div.getAttributeNames()); // ['id', 'hello']

При этом атрибуты и свойства друг с другом не связаны - можно установить одноименные свойство и атрибут в разные значения

const  div = document.createElement('div')

div.setAttribute('kek', 'true')
div.kek = false

console.log(div.getAttribute('kek')) // true

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

const div = document.querySelector('#foo'); console.log(div.getAttribute('id')); // 'foo'
console.log(div.id); // 'foo' 

div.id = 'bar'; 
console.log(div.getAttribute('id')); // 'bar' 
console.log(div.id); // 'bar'

Все эти связи описаны в спеке и описаны немного по-разному. Например, свойство crossOrigin и атрибут crossorigin, но свойство ariaLabel и атрибут aria-label

Также есть приколы, связанные с приведением типов, валидацией и дефолтами

const input = document.createElement('input'); 
console.log(input.getAttribute('type')); // null 
console.log(input.type); // 'text' 

input.type = 'number';
console.log(input.getAttribute('type')); // 'number' 
console.log(input.type); // 'number' 

input.type = 'foo'; 
console.log(input.getAttribute('type')); // 'foo' 
console.log(input.type); // 'text'

https://jakearchibald.com/2024/attributes-vs-properties/

#development #dom #domProperties #domAttributes

cpupro — лучший cpu профайлер

Не так давно я искал узкие места в витесте и вебпаке и внезапно наткнулся на cpupro. Когда я увидел, кто автор, то понял что инструмент плохим быть не может в принципе: Рома Дворнов — знак качества!

Традиционно, это самый быстрый аналайзер из существующих, способный переваривать огромные (2гб) профайлы.
Ну и по функциональности он впереди всех существуюших профайлеров — куча разных вьюшек, сортировки по пакетам/функциям и так далее. В общем, очень рекомендую!

https://github.com/lahmatiy/cpupro/releases/tag/v0.5.0

Дайджест за 2024-05-06 - 2024-05-10


React 19 Beta
Выпущен React 19 Beta! Обновляться пока рано, но уже можно готовиться к изменениям.

Первое большое изменение - Actions. Команда React не стала мудрить и взяла термин, который используется кучей тулов для менеджмента состояния и начала его использовать. В React-компонентах часто необходимо делать асинхронные действия, например, загружать данные из API. Сейчас в React это можно сделать композицией нескольких useState. А в React 19 можно использовать несколько новых хуков, которые упрощают работу с такими функциями

Deep Dive into Rspack & Webpack Tree Shaking
Крутой разбор механизма работу Tree-shaking в Webpack. Tree-shaking - это фича бандлеров, которая позволяет при сборке выкидывать код, который не нужен в конечном приложении. Решение о неиспользуемости кода принимается на разных уровнях анализа - как на основе анализа стейтментов в конкретном файле, так и на основе анализа импортов и экспортов

В Webpack tree-shaking реализуется тремя механизмами: оптимизация usedExports, оптимизация sideEffect и оптимизация dead code elimination. Оптимизации разбираются от простых к сложным.

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

Канал про митапы\конференции и другие IT-движухи в России.
В канале постится достаточно много событий разной тематики и в разных городах.

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

Рекоменндую к подписке, если вам интересны алгоритмические задачки

Hello Bun: How Sveld now deploys 2x faster on GitHub and Render
Небольшая статья про перевод инфраструктуры сборки для Svelte на Bun. В целом, миграция небольшого проекта дело достаточно тривиальное - поменять несколько команд и потратить вечерок на замену небольших конструкций кода (для автора это cli-скрипт и код авто-тестов)

The Front End Developer (Engineer) Handbook 2024
Невероятно огромный handbook про профессию фронтенд инженера в 2024 году. В хендбуке описано все - начиная от определения профессии, переходя через базовые знания (работы сети например) и заканчивая обзором современных инструментов и практик.

Рекомендую к просмотру

HTML attributes vs DOM properties
Джейк Арчибальд написал хорошую статью про разницу между HTML Атрибутами и свойствами DOM-элемента. Я, честно говоря, никогда даже об этом не задумывался - работает и работает. В статье хорошо объясняется разница между ними, а также показываются подводные камни при работе с ними

Репост cpupro — лучший cpu профайлер
это самый быстрый аналайзер из существующих, способный переваривать огромные (2гб) профайлы.

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

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

Development notes from xkcd's "Machine"

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

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

Так, относительно игроков принципы были следующие:
- Дать больше возможностей игрокам, даже ценой корректности создаваемых машин. Можно было бы сделать так, чтобы все было строго детерминировано и шары все летели в одной карте только по одному маршруту. Но это а) не так весело б) ограничивает игроков
- Т.к. все отдельные песочницы должны склеиваться в одно огромное поле, то необходимо зафиксировать "интерфейс" - откуда приходят шары и куда должны уходить. Что нужны шары уходят в нужные дырки даже проверяется автоматикой.
- Сколько нужно ждать, чтоб убедиться, что шары действительно летят туда, куда нужно? Ведь можно построить весьма заковыристый механизм, который будет очень долго жонглировать шарами. Разработчики приняли решение, что шары должны достигать своей цели за 30 секунд

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

Про техническую сторону написано не очень много: как движок физики был взят Rapier (написан на Rust, запускается в WASM). Над Rapier был написан UI на React с кастомным контекстом, который управляет объектами Rapier. Использование React позволило легко создавать виджеты, которые влияли на физику (например, Вентилятор). Также удобным оказалась цикл жизни React-компонентов - при скроле холста с механизмами, те механизмы, которые пропали из вида анмаунтились в React, что убирало объекты из Rapier. Получается, что нет на экране - нет и в симуляции физики, что звучит как хороший паттерн. В статье есть ссылки на репозиторий с реализацией и код там выглядит внушительно.

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


https://chromakode.com/post/xkcd-machine/

#development #javascript #react #xkcd

The evolution of Figma’s mobile engine: Compiling away our custom programming language

Статья от команды Figma про то, как они мигрировали с языка Skew на Typescript. Если я правильно понял, Skew - это сайд-проект с ранних дней Figma, цель которого - предоставить язык, который быстро работает и компилируется.

Основные причины, по которым решили отказаться от Skew в пользу Typescript'а заключаются в следующем:
- Тяжело масштабировать разработку т.к. специалистов по Skew нет на рынке и никто его учить не хочет
- Typescript стал де-факто стандартом в вебе и заимел много полезных фичей (особенно по сравнению с временами, когда Figma только стартовала) и имеет прекрасный тулинг вокруг
- Мобильные браузеры стали поддерживать WASM, что позволяет перевести наиболее требовательные к производительности части кода в WASM

Т.е. в целом 2 основных причины: WASM позволяет портировать наиболее "горячий" код без потери производительности (а по замерам команды, потеря производительности при компиляции в JS составляет в 2 раза по сравнению с WASM), а Typescript позволяет разрабатывать на современном популярном языке остальные части.

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

Первая фаза: разработали транспайлер Skew => Typescript. Конечно же не без проблем и их приходилось фиксить.
Вторая фаза: когда генерируемый код стал похож на работающий, начали отдавать его пользователям
Третья фаза: когда убедились, что весь код работает хорошо, просто запустили транспиляцию Skew => Typescript и удалили все Skew исходники

Отдельного внимания заслуживает транспилятор Skew => Typescript. В целом Skew уже умел билдится в Javascript, поэтому транспиляция в Typescript делалась не с нуля. Тем не менее, во время создания транспилятора нашлись интересные нюансы

Например, использование деструктуризации замедляет код на 25%, поэтому при обращении к arguments Skew генерирует код, в котором доступ к элементам массива осуществляется по индексу.

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

myObject.myFunc(a, b)
// becomes...
myFunc(myObject, a, b)

Эта оптимизация как-то ускоряет код и она была в Skew, но её нет в Typescript. Я так понял, что ребята решили отказаться от нее и на основе логов искали код, который рассчитывал на эту фичу Skew

Еще одна прикольная штука связанная с компилятором - это то что ребята сделали мапинг сорс мапов javascript => typescript => skew. Первую часть (ts => js) давал esbuld из коробки. Вторую часть (ts => skew) ребята написали сами.



https://www.figma.com/blog/figmas-journey-to-typescript-compiling-away-our-custom-programming-language/

#development #typescript #figma #migration #skew

How to document your JavaScript package

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

Отдельно замечу, что реализация автодокументации от JSR очень хороша. Идея проста - пишите документацию к коду, а инструмент это все распарсит и опубликует в удобном для людей виде. Но, не смотря на простоту этой идеи, хороший реализаций не так много. Если грамотно писать JSDoc к пакету и публиковать его в JSR, то JSR сделает реальную крутую автодоку к пакету.

Что умеет делать JSR с JSdoc:
- Красиво выводит форматирование доки. Можно использовать markdown внутри JSDoc и быть уверенным, что форматирование будет корректно отображено
- Резолвит ссылки на другие сущности внутри пакета
- Объединяет типы TS и jsdoc
- Красиво выводит примеры использования кода
- Автоматически проверяет корректность примеров использования кода

Последняя фича отлично реализована в Rust. Её лучше всего показывать на примере.

Допустим, у вас есть функция sum и вы к ней в JSDoc приводите пример запуска кода и его результат

/**
 * Adds two values and returns the sum.
 *
 * @example
 * \`\`\`ts
 * import { sum } from "jsr:@deno/sum";
 * const finalValue = sum(1, "this is a string"); // 3
 * \`\`\`
 */
export function sum(value1: number, value2: number): number {
  return value1 + value2;
}

В данном случае в JSDoc ошибка, ведь нельзя прокинуть "this is a string" как число. Deno умеет тестировать доки и найдет ошибку

deno test --doc
Check file:///Users/sum.ts$8-13.ts
error: TS2345 [ERROR]: Argument of type 'string' is not assignable to parameter of type 'number'.
const finalValue = sum(1, "this is a string");

Выглядит интересно. Правда в статье не до конца раскрывается, проходит ли только typecheck, или же сниппеты прям запускаются, как в Rust? Предполагаю, что пока только typecheck, но проверять что примеры из JSDoc запускаются и делают то, что от них ожидается. было бы супер круто.

В статье также описывают бест-практисы по ведению JSDoc в проекте.

https://deno.com/blog/document-javascript-package

#development #javascript #deno #jsr #jsdoc

Дайджест за 2024-05-13 - 2024-05-17


Development notes from xkcd's "Machine"
Достаточно знаменитый сайт с узнаваемыми комиксами xkcd в апреле запускал Machine - игру-песочницу, в которой игроку необходимо расставить различные механизмы так, чтобы входящие в поля шарики вылетали в нужном направлении. Наверное, лучше увидеть это глазами прямо в статье, потому что словами описать сложно. При этом песочницы разных игроков склеиваются в огромную безразмерную Machine, в которой шарики циркулируют бесконечно

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

The evolution of Figma’s mobile engine: Compiling away our custom programming language
Статья от команды Figma про то, как они мигрировали с языка Skew на Typescript. Если я правильно понял, Skew - это сайд-проект с ранних дней Figma, цель которого - предоставить язык, который быстро работает и компилируется.


How to document your JavaScript package
Хорошая статья от команды Deno про то, как писать документацию к пакету в виде JSDoc. В рамках данной статьи рассказывается, как пользоваться JSDoc и как JSR использует JSDoc для автоматического создания документации к пакету.

Отдельно замечу, что реализация автодокументации от JSR очень хороша. Идея проста - пишите документацию к коду, а инструмент это все распарсит и опубликует в удобном для людей виде. Но, не смотря на простоту этой идеи, хороший реализаций не так много. Если грамотно писать JSDoc к пакету и публиковать его в JSR, то JSR сделает реальную крутую автодоку к пакету.

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

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

ECMAScript proposal: Promise.withResolvers

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

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

const tasks = []
function someTask(id) {
   let _resolve;
   const promise = new Promise(resolve => { _resolve = resolve})
   // Сохраняем в очередь данные и функцию для резолва
   tasks.push({resolve:_resolve, id})
   // Возвращаем promise
   return promise;
}

// setInterval - как показатель, что бизнес-логика где-то в другом месте
// и соответственно резолвить надо тоже в другом месте
setInternval(()=>{
  for(let task of tasks) {
      // Выполнили всю логики, резолвим
      task.resolve(task.id)
  }
}, 10000)

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

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

function getPromiseWithResolvers() {
   let _resolve, _reject
   const promise = new Promise((res, rej)=>{
      _resolve = res;
      _reject = rej;
   })
   return {promise, resolve: _resolve, reject: _reject}
}

И именно это и делает новое API

 const { promise, resolve, reject } = Promise.withResolvers();

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

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

https://2ality.com/2024/05/proposal-promise-with-resolvers.html

#development #javascript #Promise

Athena Crisis is now Open Source

Пока все носятся с выводом в опен-сорс React компилятора, я показываю вам вывод в опен-сорс игры, написанной на TypeScript. Разработчик игры Athena Crisis решил выложить более 100 000 строк исходников игры в опенсорс. Достаточно редко можно посмотреть на то, как реализованы большие комерческие игровые проекты на веб-технологиях. Это как раз тот случай

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

https://cpojer.net/posts/athena-crisis-open-source

#development #javascript #Promise

React Google Maps

Вышел релиз 1.0.0 пакета react-google-maps. Честно сказать, не залазил далеко во внутренности, но уверен, что многие из вас используют Google Maps, а тут вышел первый стабильный релиз библиотеки для работы с Google Maps внутри React. Кому-то точно окажется интересным

https://visgl.github.io/react-google-maps/

#development #javascript #react #library #googleMaps

В эти выходные (25-26 мая) в Новосибирске проходит конференция Codefest, на которой я буду рассказывать про парное программирование. Я расскажу про бест-практисы проведения парного программирования и какие преимущества от этой техники мы наблюдаем конкретно в моей команде. Приходите, развиртуализируемся!

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

Дайджест за 2024-05-20 - 2024-05-22

ECMAScript proposal: Promise.withResolvers
Недавно в стандарт языка попала фича, которая немного упрощает кейсы, когда нужно создать промис и управлять резолвом промиса снаружи. Новое API: Promise.withResolvers. В статье разбирается основная проблема, из-за которое появилось API, само API, а также приводится несколько примеров использования

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

Athena Crisis is now Open Source
Пока все носятся с выводом в опен-сорс React компилятора, я показываю вам вывод в опен-сорс игры, написанной на TypeScript. Разработчик игры Athena Crisis решил выложить более 100 000 строк исходников игры в опенсорс. Достаточно редко можно посмотреть на то, как реализованы большие комерческие игровые проекты на веб-технологиях. Это как раз тот случай

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

React Google Maps
Вышел релиз 1.0.0 пакета react-google-maps. Честно сказать, не залазил далеко во внутренности, но уверен, что многие из вас используют Google Maps, а тут вышел первый стабильный релиз библиотеки для работы с Google Maps внутри React. Кому-то точно окажется интересным



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

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

JavaScript unit testing frameworks in 2024: A comparison

Обзор на инструментарий для юнит-тестов в JavaScript. За основу взяты результаты опроса stateofjs. Рассмотрено 11 инструментов, для каждого из них написаны свои плюсы, минусы и особенности.

В целом статья хороша как обзор инструментов, но при этом местами статья ставит в ступор: между собой сравниваются тест-фреймворки, фреймворки для браузерных тестов, сторибук и react-testing-library. Jest, к моему большому удивлению, имеет первым плюсом performance. В общем, контент немного странный, но в целом из него можно извлечь пользу.

https://raygun.com/blog/javascript-unit-testing-frameworks/

#development #javascript #testing

React 19 lets you write impossible components

Статья про преимущества от использования новых фичей в React19. Как я понял, команда Mux активно использует фичи, связанные с серверными компонентами React, и очень довольна ими. Основные преимущества связаны с улучшением DX и уменьшением бандла приложения.

Использование серверных компонентов позволило уменьшить на 20-90% размер бандлов разных страниц. В основном, за счет того, что у Mux очень статичные страницы - документация и маркетинговые лендинги. Большую часть контента достаточно отрендерить только на сервере.

Гораздо интереснее история с серверными компонентами.

Один из основных плюсов с точки зрения DX, это то, что теперь не нужно создавать API-ендпоинты. Т.е. если компоненту нужны данные - он просто их запрашивает (например из базы), а фреймворк уже сам разберется, как сделать так, чтобы данные попали в браузер. Плюсом к этом идет нативная интеграция с Suspense, которая позволяет описать загрузку данных и не думать о том, что это негативно повлияет на пользовательский опыт.

Также команда Mux очень сильно полюбила серверные экшны и, опять же, за очень хороший DX - достаточно просто писать React-код и не думать о бойлерплейте. Например, есть маркетинговый лендинг с формой. Раньше, чтобы отправить заполненную форму, необходимо было создать API-ендпоинт, который бы принимал данные, а к этому API-ендпоинту необходимо было бы обращаться POST-запросом. Теперь же достаточно сделать серверный form action, а все сетевое взаимодействие заберет на себя фреймворк.

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

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

https://www.mux.com/blog/react-19-server-components-and-actions

#development #javascript #react #reactServerComponents

Portable stories for Playwright Component Tests

Статья в блоге Storybook, про тестирование портативных историй с помощью Playwright Component Tests.

Если совсем коротко, то в Playwright есть возможность запустить браузер и отрендерить там JSX-разметку так, как мы привыкли await mount(<SomePage />). Эта фича называется Playwright Component Tests. Storybook же предоставляет теперь удобное API для экспорта историй как компонентов. Смешивая эти две фичи, можно писать тесты на верстку в Storybook через playwright

Например, у вас есть какие-то истории. Вы можете их получить с помощью API storybook composeStories

import { composeStories } from '@storybook/react'  // or @storybook/vue3
import * as stories from './RestaurantCard.stories'

// Each of these components can be rendered in other environments
const { Default, New, Closed, Click Me Load More } = composeStories(stories)

Теперь, можно рендерить эти стори где угодно, например в Playwright CT. Правда сниппет с превращением историй через composeStories необходимо реэкспортить через отдельный файл из-за особенностей инфраструктуры сборки и запуска Playwright

// RestaurantDetailPage.spec.tsx
// For Vue3, import from '@storybook/vue3/experimental-playwright'
import { createTest } from '@storybook/react/experimental-playwright'
// For Vue3, import from '@playwright/experimental-ct-vue'
import { test as base, expect } from '@playwright/experimental-ct-react'

import stories from './RestaurantDetailPage.stories.portable'

const test = createTest(base)

test('Default', async ({ mount }) => {
  // The mount function will execute all the necessary steps in the story,
  // such as loaders, render, and play function
  await mount(<stories.Default />)
})

test('WithItemsInTheCart', async ({ mount, page }) => {
  await mount(<stories.Success />)
  await page.getByLabel('menu item').first().click()
  await page.getByLabel('increase quantity by one').click()
  await page.getByLabel('confirm').click()
  await expect(page.getByLabel('food cart')).toContainText('€25.50')
})

Зачем это нужно? В Playwright CT есть очень крутые фичи и интеграции с IDE. Например, можно буквально в плагине в IDE открыть отрендеренную верстку и накликать действия и, наверное, проверки. Это показано небольшим видосом в самой статье и выглядит, если честно, очень круто.

Также можно интегрироваться не только с Playwright, но и другими инструментами. Например с Jest. Наверное в скором времени по-экспериментирую с composeStories в текущем рабочем проекте, выглядит интересно

https://storybook.js.org/blog/portable-stories-for-playwright-ct/

#development #javascript #storybook #testing

Web Platform Status

Альтернатива caniuse - webdevstatus. Сайт показывает процент поддержки фичи разными браузерами.

https://webstatus.dev

#development #caniuse #web

Современный гайд по CSS-фигурам

Колоссальное. Темани Афиф давно делится демками и статьями, как при помощи CSS рисовать всякое интересное. Бывает же такое, что нам надо сверстать что-нибудь «эдакое». Хочется, но сложно и не можется.

В сборнике есть и clip-path, и разные сочетания background-image, и математика, и маски, и другие техники. Всё адаптивное и кастомизируемое. Сохранил себе в закладки, если вдруг надо будет верстать, чтобы просто копировать в проект.

https://www.smashingmagazine.com/2024/05/modern-guide-making-css-shapes/

The Hagakure #80: Why Coaching (Really) Matters for Engineering Leadership

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

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

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

https://hagakure.substack.com/p/the-hagakure-80-why-coaching-really

#managment #coaching #leadership