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

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

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

Node.js Performance Hooks: Mastering the Mental Model
Статья, объясняющая, как работают performance-хуки в nodejs. Если коротко, в nodejs есть API для обработки всех замеров через performance. Собственно это API и называется хуками.

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

Node.js Test Runner: A Beginner's Guide
Неплохая статья, рассказывающая про то, как работать с nodejs тест-ранером. Статья по шагам раскрывает возможности этого тест-ранера, включая не только самые обычные API (как сравнивать, как скипать тест), но также раскрываются возможности для мокирования модулей и таймеров.

⭐️The Gap: An exploration of the pain points that CSS gap solves.
Хорошая статья с хорошей визуализацией про то, почему в css появилось свойство gap и почему оно лучше всех предыдущих решений.

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

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

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

Why, after 6 years, I’m over GraphQL

Отличная статья про проблемы GraphQL. Особенно интересна она тем, что автор буквально залетел в GraphQL 6 лет назад, когда еще был hype train, но теперь он не может советовать использовать GraphQL в большинстве проектов.

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

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

Так как GraphQL это язык запросов, то пользователь можно создавать разные странные запросы. Например, можно в 128 байт уместить запрос, ответ на который возвращает мегабайты данных и который может полоржить сервер. С этим приходится бороться ограничивая максимальную вложенность полей в запросе и отдельно рассчитывая "сложность" доставания каждого поля. В то же время в REST достаточно поставить разные стратегии rate limiter для разных енд-поинтов

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

query {
  __typename @a @b @c @d @e ... # imagine 1k+ more of these
}

И чтобы собрать ответ с ошибкой сервер потратит в 2000 раз больше памяти, чем занимает сам запрос

Также автор дважды подмечает N+1 проблему, которую можно решать через паттерн Dataloader. Проблема с GraphQL не только в том, что N+1 актуальна для загрузки данных, но она актуальна и для авторизации.

В целом, конечно, ничего нового в этой статье нет - GraphQL очень удобен для запроса данных, но не очень удобен для безопасного и производительного резолва этих данных. Кроме того, для большинства решений и дебага, backend-разработчику проще работать с REST, чем с GraphQL.

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

https://bessey.dev/blog/2024/05/24/why-im-over-graphql/

#development #graphql #recommended

Test-Driving HTML Templates

В последнее время был очень популярен подход с чистым SPA при котором нам не нужен сервер и весь рендеринг происходит на стороне браузера. Однако сейчас все чаще становится популярным рендеринг на сервере. В блоге Мартина Фаулера опубликована статья, рассказывающая, как применять TDD при рендере HTML-шаблонов на "серверных" языках.

В целом статья разделяется на 3 этапа
1. Проверка корректности HTML. Первоначально было бы неплох отбрасывать невалидную вёрстку. Для этого на целевом языке берется библиотека, умеющая проверять валидность HTML
2. Проверка бизнес-логики. В HTML-шаблонах содержится логика и её нужно проверять. Цель таких тестов - отбросить все лишнее и проверять только то, что важно. В примере из статьи проверяется, что выставлены корректные статусы и задач в ToDoList
3. Тестирование поведения. Для того чтобы протестировать реальное поведение UI, нужно уметь проверять, что приложение делает на условный клик и как оно обрабатывает ответ сервера (например, при отправке формы). Для этого нам нужен браузер, поэтому автор предлагает использовать Playwright для тестирования. В этих тестах предлагается мокировать вообще все сетевые запросы, что немного странно, но возможно применимо в каких-то примерах.

Чем интересна данная статья: она показывает как применять TDD к разработке UI. В чистом виде вам эта статья может не понадобится (т.к. в целом проще разрабатывать через storybook и скриншот-тесты), но идея использовать TDD может быть полезна


https://martinfowler.com/articles/tdd-html-templates.html

#development #martinFowler #TDD #html

Data Fetching Patterns in Single-Page Applications

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

Сначала автор описывать, как работать с состоянием загрузки. У нас есть 3 основных состояния: данные грузятся, данные не удалось загрузить, данные загружены. Первый паттерн - Asynchronous State Handler - необходимо написать генерализированный код, инкапсулирующий в себя управление загрузкой и отдающий в UI только знания о текущем состоянии. Самое ценное в этом паттерне - это разделение кода UI от кода загрузки данных. В рамках статьи автор реализует паттерн, создавая генерализированный хук для загрузки данных по урлу.

Если у нас в рамках компонента есть под-компонент, которому также необходимы данные, то мы можем поймать проблему водопада запросов. Например, есть компонент профиля, внутри него есть компонент друзей. Сначала мы показываем скелетон для загрузки профиля, загружаем данные профиля, узнаем что надо грузить друзей - снова ждем. Здесь нам на помощь приходит Parallel Data Fetching - нужно уметь грузить данные параллельно, чтобы не заставлять ждать пользователя дольше необходимого

Для того чтобы не нагружать UI-код обработкой долгой загрузки или ошибки загрузки, выделяется паттерн Fallback Markup - когда мы выделяем обработку этих состояний в отдельные под-компоненты, а их использование описывается декларативно. В React, например, это легко делать с помощью Suspense.

Если же мы заранее знаем, какие данные пользователю понадобятся, то мы можем загружать их заранее и тем самым реализовывать паттерн Prefetching. Например, используя <link rel="preload">. Но это подходит только для данных, о загрузке которых мы уверены еще на уровне первоначального рендера страницы. Но иногда мы получаем эту уверенность по другому тригеру. Например, наше приложение предоставляет большой список и при клике на какую-то кнопку нужно загрузить и отобразить дополнительную информацию о конкретном элементе списка. Вместо того, чтобы загружать данные только по клику, мы можем их предзагружать если пользователь водит мышкой по компоненту больше скольки-то милисекунд. Это может привести к излишней загрузке в некоторых кейсах, но если мы, например, знаем на основе нашей аналитики, что 90% пользователей, которые держат мышку на элементе дольше 300мс кликают на кнопку загрузки - то можно облегчить жизнь 90% пользователей.

Последний рассмотренный паттерн - Code Splitting. Не весь код приложения нужен пользователю прямо сейчас. Вместо этого можно загружать верстку или логику только тогда, когда она реально понадобилась.

https://martinfowler.com/articles/data-fetch-spa.html#ChoosingTheRightPattern

#development #martinFowler #SPA #javascript

https://habr.com/ru/companies/ispring/articles/822975/

Статья о проведении автоматического рефакторинга с помощью JS CodeShift. Есть проект на Google Closure Library и команда решила перевести код на ECMAScript 6. Поскольку проект большой (900 000 строк кода), было решено сделать это автоматизированно.

Почему решили отказаться от Google Closure Library:
• Длинные пространства имён
• С Google-модулями плохо работают подсказки IDE
• Появление скрытых зависимостей
• Актуальность технологий

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

Сделать такой рефакторинг с помощью регулярных выражений невозможно, но его легко сделать с помощью работы с AST (Abstract Syntax Tree). Для этого был выбран JS CodeShift.

Описать изменение таких файлов с помощью регулярных выражений в общем случае невозможно. Для проверки гипотезы были отрефачены 3 небольших (500 файлов) проекта. Весь рефакторинг занял 1 час, включая ручные правки сложных моментов.

Автор даёт два совета:
• Начинать с небольших и простых модулей или проектов.
• Не следует пытаться автоматизировать всё. Автоматический рефакторинг хорошо покрывает часто встречающиеся паттерны. Остальное легче поправить вручную. Т.е. утрируя, можно следовать правилу 80/20 - 80% кейсов рефакторинга можно покрыть автоматикой, остальные 20% лучше сделать руками, чтобы рефакторинг не превратился в первые 80% работы и вторые 80% работы


Мощь AST в действии, или как переписать код 10 летней давности на ES6-модули и ничего не сломать

#development #javascript #ast #refactoring #jscodeshift

Дайджест за 2024-06-17 - 2024-06-20

⭐️Why, after 6 years, I’m over GraphQL
Отличная статья про проблемы GraphQL. Особенно интересна она тем, что автор буквально залетел в GraphQL 6 лет назад, когда еще был hype train, но теперь он не может советовать использовать GraphQL в большинстве проектов.

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

Test-Driving HTML Templates
В последнее время был очень популярен подход с чистым SPA при котором нам не нужен сервер и весь рендеринг происходит на стороне браузера. Однако сейчас все чаще становится популярным рендеринг на сервере. В блоге Мартина Фаулера опубликована статья, рассказывающая, как применять TDD при рендере HTML-шаблонов на "серверных" языках.

Data Fetching Patterns in Single-Page Applications
Статья в блоге Мартина Фаулера про паттерны загрузки данных в SPA-приложениях. Загрузка данных в SPA-приложениях - не самая простая задача, т.к. необходимо учитывать все нюансы асинхронно природы этого действа - например, необходимо обрабатывать ошибки и долгую загрузку. В статье по-шагам реализуются основные паттерны для загрузки данных. Если вы уже "собаку съели" на загрузке данных, то вы вряд ли увидите в этой статье что-то новое. Однако, сама статья весьма неплоха для начинающих разработчиков.

Сначала автор описывать, как работать с состоянием загрузки. У нас есть 3 основных состояния: данные грузятся, данные не удалось загрузить, данные загружены. Первый паттерн - Asynchronous State Handler - необходимо написать генерализированный код, инкапсулирующий в себя управление загрузкой и отдающий в UI только знания о текущем состоянии. Самое ценное в этом паттерне - это разделение кода UI от кода загрузки данных. В рамках статьи автор реализует паттерн, создавая генерализированный хук для загрузки данных по урлу.

Мощь AST в действии, или как переписать код 10 летней давности на ES6-модули и ничего не сломать
Статья о проведении автоматического рефакторинга с помощью JS CodeShift. Есть проект на Google Closure Library и команда решила перевести код на ECMAScript 6. Поскольку проект большой (900 000 строк кода), было решено сделать это автоматизированно.


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

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

Conditionals on Custom Properties

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

Изначально я сильно удивился, что в css добавляют что-то подобное. Но, оказывается какое-то подобие условий уже можно было реализовать через calc и custom-properties calc(var(--test) * var(--if-true) + (1 - var(--test)) * var(--if-false)). Теперь же рабочая группа развития CSS обсуждает введение условий в язык.

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

https://geoffgraham.me/conditionals-on-custom-properties/

#development #css #customProperties

Blazing Fast Websites with Speculation Rules

Огромная статья про новую фичу в вебе - speculation rules. В статье подробно описывается, что это за фича, какие у нее сценарии использования, какие есть плюсы и минусы.

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

<script type="speculationrules">
  {
    "prerender": [
      {
        "urls": ["/shop", "/contact"]
      }
    ]
  }
</script>

Есть 2 вида спекуляций: prerendering и prefetching (т.е. пререндер и предзагрузка).

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

Prefetching загружает ключевые ресурсы страницы, но не делает пререндер. Т.е когда пользователь кликает на ссылку на страницу, которая предзагружена, в браузере уже все загружено и нужно её только отрисовать.

Какие преимущества у этой фичи:
- Во первых, это нативная фича, для которой даже не нужен JS-код
- Во вторых, в вебе уже есть похожие фичи (link rel=preload например), но ни одна из них не может загружить контент страницы и все связанные с ним ресурсы, а также сделать пререндер страницы.
- Конфигурирование спекуляций очень гибкое, про это я опишу ниже


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

Например, по матчингу урла ресурса

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": {
          "and": [
            { "href_matches": "/*" },
            { "not": { "href_matches": "/logout" } }
          ]
        }
      }
    ]
  }
</script>

<!-- ✅ Prerendered -->
<a href="/shop">Shop</a>

<!-- ✅ Prerendered -->
<a href="/about">About</a>

<!-- ❌ Not prerendered -->
<a href="/logout">Logout</a>

Также можно указать, чтобы пререндер происходил, только если пользоватьель делает hover над элементом (и держит его более 200мс)

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": {
          "href_matches": "/*"
        },
        "eagerness": "moderate"
      }
    ]
  }
</script>

А еще можно управлять пререндером на основе css-селекторов

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": {
          "and": [
            { "href_matches": "/*" },
            {
              "not": {
                "selector_matches": ".no-prerender"
              }
            }
          ]
        }
      }
    ]
  }
</script>

Также спекуляции отображаются в девтулах: появляется отдельная вкладка в application, где можно посмотреть предзагруженные страницы и правила. Также предзагрузка страниц отображается в Network и Performance.

Можно из JS понять, предзагружена страница или нет.

const isPagePrerendered =
  document.prerendering ||
  window.performance?.getEntriesByType?.("navigation").at(0)?.activationStart >
    0;

https://www.debugbear.com/blog/speculation-rules

#development #performance #speculationRules #recommended

How React 19 (Almost) Made the Internet Slower

React 19 замедляет интернет!!!!! Достаточно громкий заголовок у статьи, но она посвящена конкретному кейсу - изменена логика обработки асинхронных компонентов в Suspense.

Если раньше два компонента в рамках одного Suspense параллельно грузили свои данные, то теперь это происходит последовательно - т.е. сначала первый компонент загружает свои данные, затем второй компонент делает то же самое.

Пример кода

function App() {
  return (
    <>
      <Suspense fallback={"Click Me Load More..."}>
        <ComponentThatFetchesData val={1} />
        <ComponentThatFetchesData val={2} />
        <ComponentThatFetchesData val={3} />
      </Suspense>
    </>
  );
}

const ComponentThatFetchesData = ({ val }) => {
  const result = fetchSomethingSuspense(val);

  return <div>{result}</div>;
};

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

Видимо, команда React решила немножко оптимизировать рендер и React перестал рендерить сиблингов в Suspense, в случае отлавливания промиса. Однако, это изменение очень сильно воздействует на перформанс React-приложений.

Команда React пообещала пофиксить эту проблему, поэтому в целом ничего страшного не произошло - сообщество нашло проблему, обсудило, разработчики обещали пофиксить. Историю со счастливым концом.


https://blog.codeminer42.com/how-react-19-almost-made-the-internet-slower/

#development #javascript #react #react19 #suspense #performance

React Internals Explorer - easily see how React works

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

В инструменте есть пресеты для изучения разных механик React, а также возможность запускать код в React18 и React19. В том числе там можно посмотреть разницу в рендере Suspense с несколькими асинхронными компонентами, про которую я писал в прошлом посте.

https://jser.pro/ddir/rie

#development #javascript #react #tool #recommended