В эти выходные (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

Дайджест за 2024-05-27 - 2024-05-31

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

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

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

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

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

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

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

The Hagakure #80: Why Coaching (Really) Matters for Engineering Leadership
Лиды в IT-командах очень часто, фокусируются на инструментах, а не людях. Во многом это потому, что тяжело научиться быть хорошим менеджером для людей. Редкий IT-менеджер проходил какое-то структурированное обучение, а бесконечное чтение статей и книжек конечно приносит пользу, но само по себе недостаточно для настоящего обучения

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

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

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

Why react Query

Большая и хорошая статья про то, зачем и почему появился react query. Статья идет от простого к сложному и объясняет, как тяжело в React учесть все нюансы для загрузки данных (понадобится много хуков и много бойлерплейта) и как React Query забирает на себя весь бойлерплейт и улучшает DX, производительность и качество решения.

Как и всегда на ui dev, в стате понятные примеры кода и крутая интерактивная анимация. Рекомендую к прочтению

https://ui.dev/why-react-query

#development #javascript #react #reactQuery #recommended

20 июня в Новосибирске пройдет Тинькофф Техтолк для тимлидов

В программе 2 доклада и обсуждение после них. Общая тема - развитие процессов в команде

Я там буду там рассказывать, как мы в команде вместе обучались процессным практикам (начиная от принципов agile и заканчивая современными практиками ведения задач)

Второй доклад будет от Дениса Вайткуса и он тоже очень хорош.

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

Если вам интересна эта тема - рекомендую к посещению

Speed Up Your Playwright Scripts with Request Interception

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

В статье разобраны несколько сценариев для мокания запросов в Playwright: для неважного контента можно обрывать запросы, для важного - мокировать ответ или модифицировать ответ. В целом практика подходит не только для Playwright.

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

https://www.checklyhq.com/blog/speed-up-playwright-scripts-request-interception/

#development #javascript #testing #playwright #mock

Coding my handwriting

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

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


https://www.amygoodchild.com/blog/cursive-handwriting-in-javascript

#development #javascript

Understand errors and warnings better with Gemini

Еще один виток использования AI в рабочих инструментах: в Chrome DevTools теперь можно подключить AI, который будет объяснять ошибки в консоли. Например, у вас упал запрос из-за CORS. Тыкаете кнопку и AI вам рассказывает, что это за ошибка и что конкретно нужно сделать, чтобы она исчезла.

https://developer.chrome.com/docs/devtools/console/understand-messages

#development #javascript #chrome #devtools

Regexper

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

https://regexper.com/

#development #regexp

Дайджест за 2024-06-03 - 2024-06-07

⭐️Why react Query
Большая и хорошая статья про то, зачем и почему появился react query. Статья идет от простого сложного и объясняет, как тяжело в React учесть все нюансы для загрузки данных (понадобится много хуков и много бойлерплейта) и как React Query забирает на себя весь бойлерплейт и улучшает DX, производительность и качество решения.

Как и всегда на ui dev, в стате понятные примеры кода и крутая интерактивная анимация. Рекомендую к прочтению

Speed Up Your Playwright Scripts with Request Interception
Небольшая статья про ускорение браузерных тестов на Playwright через мокирование сети. И проблема и решение чисто классические - они были актуальны даже 20 лет назад. Проблема: даже если мы тестируем сайт чисто загружая его и делая скриншот, инструменты для такого тестирования как правило ждут завершения всех или почти всех сетевых запросов. На каких-то сайтах это пара секунд, на других десятки. В любом случае, больше времени уходит на ожидание завершения запросов, чем на сам тест. Решение: мокать запросы, чтобы не ходить в сеть

В статье разобраны несколько сценариев для мокания запросов в Playwright: для неважного контента можно обрывать запросы, для важного - мокировать ответ или модифицировать ответ. В целом практика подходит не только для Playwright.

Coding my handwriting
Не совсем обычная ссылка, но тем не менее достаточно интересная. В статье рассказывается, как сделать рукописный шрифт с помощью p5js. Основная проблема рукописных шрифтов - это то, что начертание буквы зависит от её соседей.

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

Understand errors and warnings better with Gemini
Еще один виток использования AI в рабочих инструментах: в Chrome DevTools теперь можно подключить AI, который будет объяснять ошибки в консоли. Например, у вас упал запрос из-за CORS. Тыкаете кнопку и AI вам рассказывает, что это за ошибка и что конкретно нужно сделать, чтобы она исчезла.

Regexper
Интересный сервис, который визуализирует работу regexp. Вводите конкретный regexp, а сервис рисует диаграмму, которая показывает, как он работает. Выглядит достаточно занятно и полезно для изучения regexp

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

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

Speeding up the JavaScript ecosystem - Server Side JSX

Новая статья про ускорение JS-экосистемы. На этот раз ускоряется не какая-то конкретная библиотека, а рендер JSX на сервере. Ускорение делается за счет прекомпиляции статичного и почти-статичного JSX в html-строку. За счет этого достигается ускорение в 7-20 раз и уменьшение работы сборщика мусора в 2 раза.

Например, предположим что у нас есть следующий компонент

<h1 id="heading">hello world</h1>;

Он будет скомпилирован в

// output: newer "automatic runtime" transform  
import { jsx as _jsx } from "react/runtime";  
_jsx("h1", { id: "heading", children: "hello world" });

Но мы же видим, что компонент статичный и его можно скомпилировать сразу в html

const html = '<h1 id="heading">hello world</h1>';

Что мы получаем от такого преобразования: браузеру намного проще работать с обычными строками, чем с вызовами функций и объектами.

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

В целом это очень старый подход. Первые web-фреймворки примерно так и работали. Также, многие современные фреймворки поддерживают такую оптимизацию (svelte, vue, preact, solid).

Также автор статьи работает в Deno и эта оптимизация там завезена в Deno и может быть включена через конфиг

// deno.json  
{  
  "compilerOptions": {  
-   "jsx": "react-jsx",  
+   "jsx": "precompile",  
  }  
}

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



https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-9/

#development #javascript #performance

Node.js Performance Hooks: Mastering the Mental Model

Статья, объясняющая, как работают performance-хуки в nodejs. Если коротко, в nodejs есть API для обработки всех замеров через performance. Собственно это API и называется хуками.

Статья объясняет про особенности работы этих хуков (например, про наличие буферов у каждого обсервера).

https://pavel-romanov.com/nodejs-performance-hooks-mastering-the-mental-model

#development #javascript #performance #nodejs

Node.js Test Runner: A Beginner's Guide

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

Статья начиная с объяснения базового API для тестов - объявления тестов и проверок. Интересно, что nodejs поддерживает 2 стиля для объявления тестов - через комбинацию describe + it и через test('name', t => {})

descibe + it

import { formatFileSize } from "../formatter.js";
import { describe, it } from "node:test";
import assert from "node:assert";

describe("formatFileSize function", () => {
  it('should return "1.00 GB" for sizeBytes = 1073741824', () => {
    assert.strictEqual(formatFileSize(1073741824), "1.00 GB");
  });
});

test

import { formatFileSize } from '../formatter.js';
import { test } from 'node:test';
import assert from 'node:assert';

test('formatFileSize function', (t) => {
  t.test('should return "1.00 GB" for sizeBytes = 1073741824', () => {
    assert.strictEqual(formatFileSize(1073741824), '1.00 GB');
  });
});

Также поддерживается скип тестов и также это можно сделать двумя способами - через .skip у теста, либо же через проброс skip: true в опциях теста

import { describe, it } from 'node:test';
import assert from 'node:assert';
import { formatFileSize } from '../formatter.js';

describe('formatFileSize function', () => {
  it.skip("should return '0B' for sizeBytes = 0", () => {
    assert.strictEqual(formatFileSize(0), '0B');
  });

  it("should return '1.00 MB' for sizeBytes = 1048576", { skip: true }, () => {
    assert.strictEqual(formatFileSize(1048576), '1.00 MB');
  });
});

Доступна фильтрация по имени теста. Как в старые добрые времена, можно в имена тестов добавлять типа тэги (#tag или @tag) и запускать только тесты с этим тэгом через фильтрацию имени
node --test --test-name-pattern @large

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

import { describe, it, mock } from 'node:test';
import assert from 'node:assert';
import fs from 'node:fs';

// Mocking fs.readFile() method
mock.method(fs.promises, 'readFile', async () => 'Hello World');

describe('Mocking fs.readFile in Node.js', () => {
  it('should successfully read the content of a text file', async () => {
    assert.strictEqual(fs.promises.readFile.mock.calls.length, 0);
    assert.strictEqual(
      await fs.promises.readFile('text-content.txt'),
      'Hello World'
    );
    assert.strictEqual(fs.promises.readFile.mock.calls.length, 1);

    // Reset the globally tracked mocks.
    mock.reset();
  });
});

В версии 20.4 добавлена возможность мокирования таймеров

import { describe, it, mock } from 'node:test';
import assert from 'node:assert/strict';

describe('Mocking setTimeout in Node.js', () => {
  it('should successfully mock setTimeout', () => {
    const fn = mock.fn();
    mock.timers.enable({ apis: ['setTimeout'] });
    setTimeout(fn, 20);

    mock.timers.tick(10);
    mock.timers.tick(10);

    assert.strictEqual(fn.mock.callCount(), 1);
  });
});

Настройка мокирования таймеров достаточно гранулярная: можно настроить отдельно setTimeout, а можно Date. Из статьи правда непонятно до конца, насколько это API хорошо работает в реальных приложениях, где промис-чейны могут быть весьма нетривиальны.

Далее в статье описываются хуки (before), генерация репортов, сбор code coverage.

Из интересного, показывается пример тестирования сервера на fastify.

Рекомендую к прочтению для ознакомления с API тест-ранера nodejs

https://betterstack.com/community/guides/testing/nodejs-test-runner/

#development #javascript #nodejs #testing #nodejsTestRunner

The Gap: An exploration of the pain points that CSS gap solves.

Хорошая статья с хорошей визуализацией про то, почему в css появилось свойство gap и почему оно лучше всех предыдущих решений.

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

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

https://ishadeed.com/article/the-gap/

#development #css #gap #recommended