ts-blank-space

Bloomberg заопенсорсили свой компилятор TS в JS. Это, конечно, сложно назвать компилятором - он очень быстро удаляет весь синтаксис TS и оставляет только нативный синтаксис JS.

Сам инструмент максимально простой: парсит AST, находит токены, связанные с TS и заменяет их на пробелы (поэтому blank-space в названии).

Зачем это вообще нужно.

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

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

Оригинальный код

class Cat<T> {
  public whiskers: number;
  public tail: T;

  constructor(count: number, tail: T) {
    this.whiskers = count;
    this.tail = tail;
  }
}

throw Error();

Код, скомпилированный TS в esnext

class Cat {
    whiskers;
    tail;
    constructor(count, tail) {
        this.whiskers = count;
        this.tail = tail;
    }
}
throw Error();

Очень близко к оригиналу, но вы можете заметить что исчезли пустые строки. А это значит, что теперь stacktrace у ошибки будет указывать на другую строчку.

ts-blank-space компилирует код в такой вариант

class Cat    {
         whiskers        ;
         tail   ;

  constructor(count        , tail   ) {
    this.whiskers = count;
    this.tail = tail;
  }
}

throw Error();

Как видите, вся специфика TS была заменена на пробелы, все значимые токены остались на своих местах. Это позволяет упростить дебаг: stacktrace ошибок всегда указывает на ту же строчку и колонку, на которой стоит конструкция в оригинальном коде; также упрощается сбор сорс-мапов. Если код меняется, то сорсмапы, грубо говорят, содержат мапинг вида "вот была строчка 10 колонка 11, теперь она строчка 7, колона 8". С использованием ts-blank-space сорсмапы описываются 1 строчкой //# sourceURL=cat.ts

Простота инструмента позволяет ему быть быстрым: по бенчмаркам блумберга, если не учитывать работу с AST для сорс-мапов, то ts-blank-space уступает лишь esbuild и @swc/core. Если же учитывать мапинг сорс-мапов, то ts-blank-space является самым быстрым тулом

Простота инструмента также и ограничивает его. Поддерживается на весь синтаксис TS:
- не поддерживаются неймспейсы (declare namespace поддерживается)
- не поддерживается специфика commonJS
- енамы (declare enum поддерживается)
- Свойства класса, объявляемые в конструкторе constructor(public prop) {}

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

https://bloomberg.github.io/ts-blank-space/

#development #javascript #typescript #bloomberg #compiler

stricli

Еще 1 инструммент от Blooomberg. На этот раз - инструмент для создания cli. Основные фичи: поддержка typescript, отсутствие депенденсей, умеет и в ESM и в commonjs, умеет в автокомплит из шела, умеет в код сплиттинг и инъекцию зависимостей

https://bloomberg.github.io/stricli/

#development #javascript #typescript #bloomberg #cli

What in Zod's name?

Есть библиотека для валидации по схеме - Zod. Она достаточно популярна, но ошибки валидации от нее сложно воспринимать. Для упрощения разбора ошибок появился zod.fyi - вы вставляете в него текст ошибки, а он выдает вам человекопонятное описание, что же случилось. В целом, наверное, можно закидывать ошибку и в chatGPT.

https://zod.fyi/

#development #javascript #zod #validation

ESLint now officially supports linting of JSON and Markdown

Eslint продолжает развиваться. На этот раз представили поддержку линтинга json и markdown.

С одной стороны, линтить JSON и markdown не очень то интересно. С другой стороны есть 2 плюса: 1) можно использовать 1 инструмент для линтинга не только кода, но и json и доки на markdown; 2) сделали полноценную поддержку других языков

Получается, теперь можно писать плагины на eslint для линтинга других языков. Это позволит сообществу сделать плагины для линтинга css, html, всяких svelte и прочих форматов прямо внутри eslint. Что звучит круто

Подключение новых плагинов выглядит вот так

import json from "@eslint/json";

export default [
    {
        plugins: {
            json,
        },
    },

    // lint JSON files
    {
        files: ["**/*.json"],
        language: "json/json",
        rules: {
            "json/no-duplicate-keys": "error",
        },
    },
];

https://eslint.org/blog/2024/10/eslint-json-markdown-support/

#development #javascript #eslint #markdown #JSON

Announcing VoidZero - Next Generation Toolchain for JavaScript

Evan You (создатель vue, vite и кучи других инструментов) основал компанию, задача которой - создать тулчейн нового поколения для JS. Компания называется VoidZero. В целом, примерно те же цели что и у Rome, но доверия к Evan You намного больше - человек ультра продуктивен и делает действительно крутые инструменты.

Что уже было разработано командой Evan You
- Vite, который стал уже основным сборщиком для многих мета-фреймворков
- Самый быстрый JavaScript парсер oxc-parser, в 3 раза быстрее чем SWC
- Самый быстрый Node.js резолвер зависимостей oxc-resolver, в 28x раз быстрее чем enhanced-resolve
- Самый быстрый TS/JSX трансформер oxc-transform, в 4 раза быстрее чем SWC. Не видел его, кстати, в бенчмарке от Блумберга, где они сравнивали свой ts-blank-page
- Самый быстрый линтер oxlint, в 50–100 раз быстрее чем ESLint
- Самый фичастый (в оригинале the most feature-complete) тест-раннер для веб приложений - vitest
- Самый быстрый бандлер Rolldown. Быстрее чем esbuild и другие бандлеры, написанные на Rust

Я верю в то, что у Evan You все получится. Во первых, он уже доказал, что умеет делать крутые тулы. Во вторых, в отличии от Rome, у него уже есть куча инструментов, часть из которых уже популярны - он делает свой тулчейн не на пустом месте

https://voidzero.dev/posts/announcing-voidzero-inc

#development #javascript #EvanYou

Дайджест за 2024-10-07 - 2024-10-11

ts-blank-space
Bloomberg заопенсорсили свой компилятор TS в JS. Это, конечно, сложно назвать компилятором - он очень быстро удаляет весь синтаксис TS и оставляет только нативный синтаксис JS.

Сам инструмент максимально простой: парсит AST, находит токены, связанные с TS и заменяет их на пробелы (поэтому blank-space в названии).

stricli
Еще 1 инструммент от Blooomberg. На этот раз - инструмент для создания cli. Основные фичи: поддержка typescript, отсутствие депенденсей, умеет и в ESM и в commonjs, умеет в автокомплит из шела, умеет в код сплиттинг и инъекцию зависимостей

What in Zod's name?
Есть библиотека для валидации по схеме - Zod. Она достаточно популярна, но ошибки валидации от нее сложно воспринимать. Для упрощения разбора ошибок появился zod.fyi - вы вставляете в него текст ошибки, а он выдает вам человекопонятное описание, что же случилось. В целом, наверное, можно закидывать ошибку и в chatGPT.


ESLint now officially supports linting of JSON and Markdown
Eslint продолжает развиваться. На этот раз представили поддержку линтинга json и markdown.

С одной стороны, линтить JSON и markdown не очень то интересно. С другой стороны есть 2 плюса: 1) можно использовать 1 инструмент для линтинга не только кода, но и json и доки на markdown; 2) сделали полноценную поддержку других языков

Announcing VoidZero - Next Generation Toolchain for JavaScript
Evan You (создатель vue, vite и кучи других инструментов) основал компанию, задача которой - создать тулчейн нового поколения для JS. Компания называется VoidZero. В целом, примерно те же цели что и у Rome, но доверия к Evan You намного больше - человек ультра продуктивен и делает действительно крутые инструменты.


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

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

Bundling - Past, Present, and Future

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

Неплохо рассказывается история бандлинга и модульности в JS-экосистеме от AMD модулей и до современных тулов и проблем

https://www.youtube.com/watch?v=JUS6EPMbk0U

#development #javascript #bundlers #youtube #video

Nodejs dev - fastify book

Есть среди подписчиков чел, который делает свои сайты-документашки по популярным инструментам. Они уже попадали в канал. В этот раз появился сайт-документашка по fastify.

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

https://nodejsdev.ru/frameworks/fastify.3.book/

#development #javascript #nodejs #fastify

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

Перевод статьи о том, как shopify переходил от монолита к модульному монолиту. Shopify был огромным монолитом на Ruby on Rails, в который на протяжении более десяти лет вносили изменения свыше тысячи разработчиков. В какой-то момент команда осознала, что текущее решение необходимо декомпозировать

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

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

У shopify стоял выбор между микросервисами и модульным монолитом. Микросервисы являются стандартом в индустрии, но они также несут в себе кучу сложностей. Поэтому команда shopify решила оставить преимущества монолита (простота деплоя и поддержки инфраструктуры), но решить недостатки добавлением модульности

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

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

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

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

https://habr.com/ru/companies/piter/articles/844572/

#development #monolith #microservices #modularMonolith

Canon TDD

Статья от Кента Бека (автора TDD) про TDD. Основная проблема TDD в том, что его неправильно понимают и применяют. Кент Бек в очередной раз рассказывает, как правильно применять каноничный TDD.

В целом, TDD действительно трактуется достаточно широко. Кто-то понимает это как "тесты перед разработкой", кто-то использует для описания процесса, где просто пишутся тесты. Сам по себе термин TDD не самый удачный, т.к. по смыслу под него подходит очень много вариаций процесса разработки. Кент Бек, если мне не изменяет память, где-то уже писал что это не самое удачное название, но зато оно достаточно понятное и позволило практике закрепиться и стать популярной

В этой статье Кент Бек снова рассказывает о каноничном TDD, которое он описывал в своих книжках

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

Шаги по реализации TDD:

1) Список тестов. Первый шаг - описать список всех ожидаемых вариаций нового поведения. При этом не следует думать о том, как это будет работать технически (ОК думать о том, что состояние заказа изменится, но не ОК думать о том, в какие поля БД будут записаны данные).
2) Выберите тест из списка тестов и напишите его. Один тест. Полноценный тест с фазами подготовки, запуска и проверки. Типичные ошибки: писать тесты без проверок; писать сразу кучу тестов.
3) Сделайте так, чтобы тест прошел. Типичные ошибки: удалять проверки; копировать вычисленные значения в проверки; делать рефакторинг в этой фазе (умная мысль на запомнить - "Make it run, then make it right"). Если во время реализации вы понимаете, что нужен еще 1 тест - запишите его в список тестов из списка 1. После того как тест прошел, вычеркните его из списка тестов (он реализован)
4) Опциональный рефакторинг. Типичные ошибки: слишком глубокий рефакторинг, который не требуется сейчас; Слишком раннее создание абстракций
5) Если список те стов еще не пуст, перейдите к пункту 2.

В статье также есть крутая визуализация этого алгоритма.

https://tidyfirst.substack.com/p/canon-tdd

#development #TDD #kentBeck #recommended

Улучшение производительности рендеринга с помощью CSS content-visibility

Перевод небольшой статьи от автора emoji-picker-element (компонент для выбора эмодзи) про увеличение производительности рендера этого компонента. Каждый эмодзи состоит из двух элементов - button и img. Достаточно простая верстка. Однако, пользователи компонента пожаловались на медленную работу компонента. Оказалось, что у них более 19 тысяч эмодзи в селекте, из-за чего браузер "подвисает" на пару секунд

Для картинок уже использовался loading=lazy, поэтому такой долгий рендер не был связан с загрузкой почти 20 тысяч картинок. Можно было бы добавить виртуализированный список, но это усложняет решение и делает компонент хуже с точки зрения доступности (хотя, конечно, сложно назвать список из 20к элементов доступным в принципе)

Первым делом автор использовал css content-visibility. Это новый фукционал CSS, который позволяет "скрыть" элементы с точки зрения вёрстки и рисования. При этом контент все еще будет доступен в дереве доступности и по нему можно делать поиск по страницу (ctrl+F). Единственное что нужно - уметь предрасчитать размер скрываемых элементов.

После применения content-visibility, прирост в производительности составил 15% - заметно, но не то что ожидалось. Дальнейшее погружение в перформанс показало, что не смотря на loading="lazy", картинки все еще как-то обрабатываются браузером. Следующее решение: заменить img на background-image, но только если элемент с эмодзи появился на экране. Для этого используется IntersectionObserver. Данная техника позволила ускорится на 40%

Автор на этом остановился - он получил достаточно хорошее ускорение. Однако, это не масштабируемое решение (для списка из 200к элементов загрузка будет заметной). В идеале следовало бы использовать виртуализацию списка, но это усложняет компонент, поэтому пока остается так. Стоит заметить, что использование content-visibility и IntersectionObserver относительно "бесплатное" (делается за час времени), но дает огромное ускорение.

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

#development #css #performance

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

Bundling - Past, Present, and Future
Давненько в канале не было видео-контента. В основном, потому что я сам не люблю видео контент, больше читаю. Но вот есть неплохой видел на английском от создателя Parcel про историю бандлинга в вебе.

Неплохо рассказывается история бандлинга и модульности в JS-экосистеме от AMD модулей и до современных тулов и проблем

Nodejs dev - fastify book
Есть среди подписчиков чел, который делает свои сайты-документашки по популярным инструментам. Они уже попадали в канал. В этот раз появился сайт-документашка по fastify.

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

Деконструкция монолита: Максимально производительный подход к проектированию программ
Перевод статьи о том, как shopify переходил от монолита к модульному монолиту. Shopify был огромным монолитом на Ruby on Rails, в который на протяжении более десяти лет вносили изменения свыше тысячи разработчиков. В какой-то момент команда осознала, что текущее решение необходимо декомпозировать

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

⭐️Canon TDD
Статья от Кента Бека (автора TDD) про TDD. Основная проблема TDD в том, что его неправильно понимают и применяют. Кент Бек в очередной раз рассказывает, как правильно применять каноничный TDD.

В целом, TDD действительно трактуется достаточно широко. Кто-то понимает это как "тесты перед разработкой", кто-то использует для описания процесса, где просто пишутся тесты. Сам по себе термин TDD не самый удачный, т.к. по смыслу под него подходит очень много вариаций процесса разработки. Кент Бек, если мне не изменяет память, где-то уже писал что это не самое удачное название, но зато оно достаточно понятное и позволило практике закрепиться и стать популярной

Улучшение производительности рендеринга с помощью CSS content-visibility
Перевод небольшой статьи от автора emoji-picker-element (компонент для выбора эмодзи) про увеличение производительности рендера этого компонента. Каждый эмодзи состоит из двух элементов - button и img. Достаточно простая верстка. Однако, пользователи компонента пожаловались на медленную работу компонента. Оказалось, что у них более 19 тысяч эмодзи в селекте, из-за чего браузер "подвисает" на пару секунд

Для картинок уже использовался loading=lazy, поэтому такой долгий рендер не был связан с загрузкой почти 20 тысяч картинок. Можно было бы добавить виртуализированный список, но это усложняет решение и делает компонент хуже с точки зрения доступности (хотя, конечно, сложно назвать список из 20к элементов доступным в принципе)

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

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

Unleash JavaScript's Potential with Functional Programming

Еще одна статья про функциональное программирование в JS. Данная статья представляет собой гайд, который погружает вас в функциональное программирование шаг за шагом.

Объяснение начинается с определений - что такое примитив, что такое композируемая сущность, что такое функция и из чего она состоит и тд и тп. Заканчивается все применением каррирования.

Контент скорее полезен для джунов, позволяя им мягко погрузиться в основу композиции функций. Если вы отличаете каррирование от частичного применения и знаете что такое монады - смело скипайте - ваш текущий уровень понимания ФП выше, чем тот, который дает статья.


https://janhesters.com/blog/unleash-javascripts-potential-with-functional-programming

#development #javascript #functionalProgramming

SVG Coding Examples: Useful Recipes For Writing Vectors By Hand

Огромный гайд по рисованию SVG в JS на Smashing Magazine.

Начинается все с основ: что за поле используется в SVG, как управлять его размером, что с единицами измерения. Затем гайд переходит в варианты создания простых svg примитивов (линии, квадраты, окружности, овалы) в JS, затем переходит к более сложным техникам (полигоны, паттерны).

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

https://www.smashingmagazine.com/2024/09/svg-coding-examples-recipes-writing-vectors-by-hand/

#development #svg #recommended

How Bun supports V8 APIs without using V8 (part 1)

Команда разработки Bun рассказывают, как они поддерживают API V8 (движок гугл хрома) без использования V8. Bun стремиться быть совместимым с nodejs API, чтобы любой nodejs код можно было запускать в bun. Если nodejs для каких-то операций использует С++ библиотеки, то bun тоже их использует (или их аналоги). Сложнее обстоят дела с теми кейсами, когда реализация nodejs сделана через вызов V8. В Bun используется не V8 а JavaScriptCore (движок, используемый в safari). Поэтому прост так взять и использовать тоже самое не получается - надо либо найти аналог в JSC и убедиться что он работает также, либо написать свою имплементацию

Собственно про это и статья. В статье рассказывается про подводные камни такого подхода. 2 практических идентичных куска кода на С++ будут вести к разным результатам при использовании V8 и JSC. Статья подробно рассказывает про часть этих подводных камней с примерами С++ кода.

https://bun.sh/blog/how-bun-supports-v8-apis-without-using-v8-part-1

#development #javascript #bun

assistant-ui

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

https://github.com/Yonom/assistant-ui

#development #javascript #react #ai

Ultimate Express

Ultimate Express - http сервер с полной совместимостью с express, но реализованный на µWebSockets (это веб-сервер написанный на С++). Основная фича (помимо скорости работы) - что это drop-in замена обычному экспрессу. Если вы используется 4 экспресс, все что нужно, это поставить новый пакет npm install ultimate-express и затем по всему коду заменить express на ultimate-express.

Есть несколько ограничений и отличий от обычного express, но они минимальны.

На странице в гитхабе представлены 2 бенчмарка перформанса - в одном сравнивается обычный express и ultimate-express. В нем ускорение составляет от 4 до 12 раз. Другой бенчмарк от bun. В этом бенче ultimate-express занимает 3 место среди замеров на node.js (в общем списке он где-то 12)

Крутая либа по нескольким причинам. Во первых, чуваки сделали быстрый http-сервер. Во вторых, они сделали полную поддержку API express, что позволяет переехать, заменив только импорты (ну вообще можно и без замены импортов обойтись, поправив алиасы для импортов).

https://github.com/dimdenGD/ultimate-express

#development #javascript #express #httpServer

Дайджест за 2024-10-21 - 2024-10-25

Unleash JavaScript's Potential with Functional Programming
Еще одна статья про функциональное программирование в JS. Данная статья представляет собой гайд, который погружает вас в функциональное программирование шаг за шагом.

Объяснение начинается с определений - что такое примитив, что такое композируемая сущность, что такое функция и из чего она состоит и тд и тп. Заканчивается все применением каррирования.

⭐️SVG Coding Examples: Useful Recipes For Writing Vectors By Hand
Огромный гайд по рисованию SVG в JS на Smashing Magazine.

Начинается все с основ: что за поле используется в SVG, как управлять его размером, что с единицами измерения. Затем гайд переходит в варианты создания простых svg примитивов (линии, квадраты, окружности, овалы) в JS, затем переходит к более сложным техникам (полигоны, паттерны).

How Bun supports V8 APIs without using V8 (part 1)
Команда разработки Bun рассказывают, как они поддерживают API V8 (движок гугл хрома) без использования V8. Bun стремиться быть совместимым с nodejs API, чтобы любой nodejs код можно было запускать в bun. Если nodejs для каких-то операций использует С++ библиотеки, то bun тоже их использует (или их аналоги). Сложнее обстоят дела с теми кейсами, когда реализация nodejs сделана через вызов V8. В Bun используется не V8 а JavaScriptCore (движок, используемый в safari). Поэтому прост так взять и использовать тоже самое не получается - надо либо найти аналог в JSC и убедиться что он работает также, либо написать свою имплементацию

Собственно про это и статья. В статье рассказывается про подводные камни такого подхода. 2 практических идентичных куска кода на С++ будут вести к разным результатам при использовании V8 и JSC. Статья подробно рассказывает про часть этих подводных камней с примерами С++ кода.

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

https://github.com/Yonom/assistant-ui

Ultimate Express
Ultimate Express - http сервер с полной совместимостью с express, но реализованный на µWebSockets (это веб-сервер написанный на С++). Основная фича (помимо скорости работы) - что это drop-in замена обычному экспрессу. Если вы используется 4 экспресс, все что нужно, это поставить новый пакет npm install ultimate-express и затем по всему коду заменить express на ultimate-express.

Есть несколько ограничений и отличий от обычного express, но они минимальны.

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

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

pretty-print

pretty-print - библиотека для удобного вывода в консоль любых JS-значений. Когда делаешь обычный console.log по большим объектам, то там легко наступить на кейс, когда в каком-нибудь поле выведется [Object object]. Эта "проблема" решается с помощью JSON.stringify, но либа предлагает еще кучу всякого и удобного

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

https://www.npmjs.com/package/@parischap/pretty-print

#development #javascript #library #console

Inverse Assertions

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

Логично сделать что-то типа expect(notification).not.toBeInTheDocument(). Но что, если нотификашка появляется не сразу?

Можно поставить какой-нибудь sleep. Лично я во всех проектах делаю утилку const wait = (msec) => new Promise(resolve => setTimeout(resolve, msec)), который, по сути, и есть sleep и вызывается как await wait(1000). Проблема с таким подходом, что мы либо подбираем эмпирически нужное значение ожидания, либо завязываемся на детали реализации (т.е. должны знать через сколько примерно появляется нотификашка)

Как же делать правильно. В testing-library есть waitFor - функция резолвнет промис, как только её колбек пройдет

Например

await waitFor(() => {  
  expect(notification).toBeVisible()  
})

Сам waitFor в данном случае очень полезен - мы просто пишем что ожидаем какого-то условия и это позволяет нам отвязаться от деталей реализации, а также гарантирует что мы не будем ждать лишнее время (как в случае со sleep)

Но тут нам мешает, что waitFor ожидает успешного колбека. Т.е. если мы напишем

await waitFor(() => {
    expect(notification).not.toBeInTheDocument()
})

То waitFor завершится сразу же, хотя нотификашка может появиться позже.

Решение здесь - инвертировать проверку

const notificationVisiblePromise = waitFor(() => {
    expect(notification).toBeVisible()
})
 
// Assert that the notification promise has, eventually, rejected.
await expect(notificationVisiblePromise).rejects.toThrow()

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

https://www.epicweb.dev/inverse-assertions

#development #javascript #testingLibrary #testing #assertions