Dev News от Максима Соснова

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

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

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

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

Дайджест за 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-лэйаутов. —————————————— Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегамдрузьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

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

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

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

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

Дайджест за 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 —————————————— Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегамдрузьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂