Preventing and Debugging Memory Leaks in Node.js

Большая и обстоятельная статья про работу с утечками памяти в node.js. Статья буквально начинается с объяснения механизма выделения памяти в node.js, проходит через основные паттерны утечек памяти и заканчивается на примерах нахождения предотвращения утечек

Статью можно разделить на несколько разделов. Первый раздел: про то, что память выделяется на stack'е (переменные) и heap'е (все данные с динамичным размером) и механизм работы Garbage Collector

Далее статья рассказывает про основные источники утечек памяти:
- Глобальные объекты и переменные
- Замыкания
- Таймеры

После этого - исследование причин утечек памяти. Для начала автор показывает способ с получением дампа памяти через v8 через отправку процессу node.js специальный сигнал. Собираем дамп до нагрузки, собираем дамп после нагрузки, а затем анализируем разницу с помощью Chrome Dev Tools. В статье автор подробно показывает как собрать дампы и работать с дельтой двух снапшотов.

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

В общем, очень хорошая статья про утечки памяти в node.js. Рекомендую к подробному изучению.

https://betterstack.com/community/guides/scaling-nodejs/high-performance-nodejs/nodejs-memory-leaks/

#development #recommended #nodejs #performance #memoryLeak

The Bun Shell

Каждый раз, когда необходимо написать код для какого-нибудь cli-скрипта, у нас есть 2 классических стула: писать скрипт на bash или писать скрипт на чистом node.js. Оба способа неудобны. Скрипты на bash (или powershell на windows) писать сложно т.к. там неудобный синтаксис, их сложно дебажить и поддерживать. Писать скрипты на чистом JS удобно, пока не приходится работать с окружением: вызывать существующие бинари (например ls) или работать с файловой системой. Очевидное решение - сделать инструмент на JS, который берет сильные стороны JS и bash. Один такой мы уже знает - zx от Google. Теперь же появился еще 1 инструмент от команды Bun - Bun Shell.

Bun Shell - это экспериментальный язык и интерпретатор в рамках Bun, который позволяет выполнять кросс-платформенные shell-скрипты на JavaScript и TypeScript. Он упрощает выполнение shell-команд и написание скриптов, делая их более доступными и легкими в использовании по сравнению с традиционными методами. Bun Shell хорошо интегрируется с shell системы.

Вместо тысячи слов, примеры использования Bun Shell

Использование бинарей из системы:

import { $ } from "bun";

// to stdout:
await $`ls *.js`;

// to string:
const text = await $`ls *.js`.text();

Использование переменных в командах. Обратите внимание, что filename содержит в себе преднамеренную ошибку - если вставить значение переменной в команду as is, можно нечаянно грохнуть всю файловую систему на unix-like системах. Однако bun делает безопасную вставку.

const filename = "foo.js; rm -rf /";

// This will run `ls 'foo.js; rm -rf /'`
const results = await $`ls ${filename}`;

console.log(results.exitCode); // 1
console.log(results.stderr.toString()); // ls: cannot access 'foo.js; rm -rf /': No such file or directory

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

import { $ } from "bun";

const buffer = new Response("bar
 foo
 bar
 foo
");

await $`grep foo < ${buffer}`;

Сам Bun не решается сравнивать свое решение с zx, но сравнение так и напрашивается. Я не очень хорошо помню все фишки zx, хотя использовать его приходилось. Но основная, на мой взгляд, фишка Bun Shell - это то, что он идет вместе с Bun из коробки. Никаких дополнительных пакетов, шагов установки - если у вас есть Bun, значит у вас есть и Bun Shell. И это круто.

https://bun.sh/blog/the-bun-shell

#development #bun #shell

Все оценки сроков разработки ПО — ложь

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

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

https://habr.com/ru/companies/ruvds/articles/787058/

#managment #estimation #noEstimates

Delicious Donut Components

Статья про композицию клиентских и серверных компонентов в React. Статья, в основном, фокусируется вокруг паттерна Donut Components (Пончиковые Компоненты). Серверные компоненты не могут импортироваться и использоваться в клиентских компонентах. Но можно прокидывать серверный компонент как child для клиентского. Это и есть паттерн пончика (извините, не могу удержаться от использования этого словосочетания на русском языке)

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

https://frontendatscale.com/blog/donut-components/

#development #react #reactServerComponents

TypeSpec

Команда TypeScript зарелизила инструмент для описания контрактов - TypeSpec. TypeSpec позволяет описывать контракты в удобном синтаксисе, очень похожем на TypeScript, а затем компилировать их в openapi-спеку, json schema и даже protobuf. Как я понял, можно написать свой компилятор, если вам нужно компилировать контракт во что-то еще (например в роуты nest.js)

Вот как описывается простой контроллер

import "@typespec/http";

using TypeSpec.Http;

model Pet {
  name: string;
  age: int32;
}

@route("/pets")
interface Pets {
  list(@query filter: string): Pet[];
  create(@body pet: Pet): Pet;
  read(@path id: string): Pet;
}

https://typespec.io

#development #typespec #openapi #typescript #swagger #protobuf #jsonSchema

Дайджест за 2024-01-29 - 2024-02-02

⭐Preventing and Debugging Memory Leaks in Node.js
Большая и обстоятельная статья про работу с утечками памяти в node.js. Статья буквально начинается с объяснения механизма выделения памяти в node.js, проходит через основные паттерны утечек памяти и заканчивается на примерах нахождения предотвращения утечек

Статью можно разделить на несколько разделов. Первый раздел: про то, что память выделяется на stack'е (переменные) и heap'е (все данные с динамичным размером) и механизм работы Garbage Collector

The Bun Shell
Каждый раз, когда необходимо написать код для какого-нибудь cli-скрипта, у нас есть 2 классических стула: писать скрипт на bash или писать скрипт на чистом node.js. Оба способа неудобны. Скрипты на bash (или powershell на windows) писать сложно т.к. там неудобный синтаксис, их сложно дебажить и поддерживать. Писать скрипты на чистом JS удобно, пока не приходится работать с окружением: вызывать существующие бинари (например ls) или работать с файловой системой. Очевидное решение - сделать инструмент на JS, который берет сильные стороны JS и bash. Один такой мы уже знает - zx от Google. Теперь же появился еще 1 инструмент от команды Bun - Bun Shell.

Bun Shell - это экспериментальный язык и интерпретатор в рамках Bun, который позволяет выполнять кросс-платформенные shell-скрипты на JavaScript и TypeScript. Он упрощает выполнение shell-команд и написание скриптов, делая их более доступными и легкими в использовании по сравнению с традиционными методами. Bun Shell хорошо интегрируется с shell системы.

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

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

Delicious Donut Components
Статья про композицию клиентских и серверных компонентов в React. Статья, в основном, фокусируется вокруг паттерна Donut Components (Пончиковые Компоненты). Серверные компоненты не могут импортироваться и использоваться в клиентских компонентах. Но можно прокидывать серверный компонент как child для клиентского. Это и есть паттерн пончика (извините, не могу удержаться от использования этого словосочетания на русском языке)

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

TypeSpec
Команда TypeScript зарелизила инструмент для описания контрактов - TypeSpec. TypeSpec позволяет описывать контракты в удобном синтаксисе, очень похожем на TypeScript, а затем компилировать их в openapi-спеку, json schema и даже protobuf. Как я понял, можно написать свой компилятор, если вам нужно компилировать контракт во что-то еще (например в роуты nest.js)

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

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

Knip v4

Вышла 4 версия инструмента knip. Я уже писал о нем в канале - это инструмент для нахождения в проекте неиспользуемого кода. Легко встраивается в CI и быстро начинает приносить пользу. В новой версии не особо много изменений, но самое важное из них - knip теперь работает на 80% быстрее (видимо, в том числе благодаря другому изменению - теперь knip по-дефолту не анализирует использование свойств класса т.к. это требует много ресурсов)

https://knip.dev/blog/knip-v4

#development #javascript #knip #releaseNotes

The AHA Stack

Большой сайт, посвященный AHA-стеку: Astro + htmx + alpine.js. Если коротко, то основная идея стека крутится вокруг старого доброго веба, где сайты были легки, не было кучи JS в браузере, а основную работу делали серверы. Но все это с новым удобным и современным тулингом.

https://ahastack.dev

#development #javascript #aha #astro #htmx #alpinejs

The Golden Rule of Assertions

Часто можно услышать правило "один тест - одна проверка". Проблема с этим утверждением, что его часто понимают слишком буквально, что приводит к проблемам. В статье предлагается еще 1 правило "A test must fail if, and only if, the intention behind the system is not met." (Тест должен упасть только тогда, когда намерение, заложенное в системе, не достигнуто).

Для понимания сути правила, автор приводит 2 примера его нарушения:
- Проверка внутренней имплементации, вместо внешнего поведения
- Нарушение границ теста

Пример проверки внутренней имплементации: parseCookieName использует внутри себя cookieUtils. Тест проверяет, что cookieUtils вызывается корректно, при вызове parseCookieName. Этот тест проверяет имплементацию, а поэтому упадет, когда имплементацию изменят. Например, cookieUtils будет заменен на библиотеку из npm

import { parseCookieName } from './parseCookieName'
import { cookieUtils } from './utils'

it('returns the cookie name from the given cookie', () => {
  const cookieName = parseCookieName('sessionId=abc-123')

  expect(cookieUtils.parse).toHaveBeenCalledWith(
  'sessionId=abc-123',
  { pick: ['name'] }
 )
  expect(cookieName).toBe('sessionId')
})

С границами теста пример не такой простой. Допустим, есть функция, делающая сетевой запрос

export async function fetchUser(id) {
  const response = await fetch(`https://example.com/user?id=${id}`)
  const user = await response.json()
  return user
}

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

import { fetchUser } from './fetchUser'

it('fetches the user by id', async () => {
  const user = await fetchUser('abc-123')
  expect(user).toEqual({ name: 'Cody' })
})

Эту проблему можно обойти разными способами. Например, замокировав сеть.

https://www.epicweb.dev/the-golden-rule-of-assertions

#development #javascript #testing #assertions

Heat.js - JavaScript Heat Map

Heat.js - библиотека для визуализации данных в виде Heat Map. Heat Map - это визуализация, которую вы можете видеть на github или gitlab, просматривая свою активность по созданию коммитов в разрезе дней. Библиотека поддерживает разные кастомизации: цвета, кнопки, текста, отступы. А также есть разные фичи. Например, экспорт в csv.

https://www.william-troup.com/heat-js/

#development #javascript #library

qr-code - web-component, реализующий анимированные QR-коды

Интересная библиотека для отрисовке QR-кодов. Библиотека позволяет делать анимированные QR-коды на svg, но при этом все API представляет собой web-компонент. Демка на странице проекта выглядит весьма хорошо.

https://github.com/bitjson/qr-code

#development #javascript #library

Дайджест за 2024-02-05 - 2024-02-09

Knip v4
Вышла 4 версия инструмента knip. Я уже писал о нем в канале - это инструмент для нахождения в проекте неиспользуемого кода. Легко встраивается в CI и быстро начинает приносить пользу. В новой версии не особо много изменений, но самое важное из них - knip теперь работает на 80% быстрее (видимо, в том числе благодаря другому изменению - теперь knip по-дефолту не анализирует использование свойств класса т.к. это требует много ресурсов)

The AHA Stack
Большой сайт, посвященный AHA-стеку: Astro + htmx + alpine.js. Если коротко, то основная идея стека крутится вокруг старого доброго веба, где сайты были легки, не было кучи JS в браузере, а основную работу делали серверы. Но все это с новым удобным и современным тулингом.

The Golden Rule of Assertions
Часто можно услышать правило "один тест - одна проверка". Проблема с этим утверждением, что его часто понимают слишком буквально, что приводит к проблемам. В статье предлагается еще 1 правило "A test must fail if, and only if, the intention behind the system is not met." (Тест должен упасть только тогда, когда намерение, заложенное в системе, не достигнуто).

Heat.js - JavaScript Heat Map
Heat.js - библиотека для визуализации данных в виде Heat Map. Heat Map - это визуализация, которую вы можете видеть на github или gitlab, просматривая свою активность по созданию коммитов в разрезе дней. Библиотека поддерживает разные кастомизации: цвета, кнопки, текста, отступы. А также есть разные фичи. Например, экспорт в csv.

qr-code - web-component, реализующий анимированные QR-коды
Интересная библиотека для отрисовке QR-кодов. Библиотека позволяет делать анимированные QR-коды на svg, но при этом все API представляет собой web-компонент. Демка на странице проекта выглядит весьма хорошо.


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

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

Top Front-End Tools Of 2023

Список лучших frontend-инструментов 2023-го года. Список большой и содержит всякое разное: UI-библиотеки, инструменты для CSS, AI-инструменты, инструмент для 3D-моделирования на CSS, шаблонизатор писем и многое другое. Что-то конкретно выделять не хочу, но, я думаю, каждый найдет в этом списке что-то для себя

https://www.smashingmagazine.com/2024/01/top-frontend-tools-2023/

#development #javascript #css #list

Новость для тех, кто в Новосибирске.

Тинькофф на следующей неделе (20 февраля) в своем офисе проведет неофрмальный квартирник по тестированию.
 
Темы:
— о параллельной разработке как способе достижения независимости бэклога;
— контейнерных тестах: это панацея или ловушка.

Регистируйтесь, а также зовите коллег и друзей 💛
20.02, 19:00 Нск, БЦ Кронос (ул. Советская, 5)

How to Detect Clicks Anywhere on a Page in React

Небольшая заметка про то, как трекать любой клик в рамках страницы в React. Для многих описанное в статье не будет откровением (спойлер: обработчик вешается на body), но в статье есть интересный кусок с добавлением условной логики в глобальный обработчик на основе условия "является ли событие - событием из формы". Для меня стало открытием, что у любого события есть метод composedPath, который позволяет определить, через какие элементы проходило событие.

https://spacejelly.dev/posts/how-to-detect-clicks-anywhere-on-a-page-in-react

#development #javascript #react

Tale of a Refactor

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

Простой пример в статье: это форма оплаты. Изначально она содержит 1 тип оплаты, а затем появляются еще 2 типа оплаты. Естественно, логично предположить, что могут появиться еще новые типы оплаты.

Логичный первый порыв разработчика - поставить switch case или if else в код, связанный с рендером каждого блока формы оплаты. Однако, это плохой путь, потому что фича определенного типа оплаты получается размазанной по всей кодовой базе. Кроме того, при добавлении новых способов оплаты придется трогать большой код с условиями.

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

Что-то вроде

// Обобщенный тип
type PayForm = {
   Label: Component,
   Button: Component,
   Body: Component
}

// В файле somePayType.tsx

/* До экспорта написан код, имплементирующий элементы формы */

export SomePayType: PayForm = {
   Label: () => <div> Some Pay Type </div>,
   Button: SomePayTypeButton
   Body: SomePayTypeBody
}

// В самой форме

const PayFormComponent = () => {
   /* всякий разный код */

   // Узнаем, какой тип оплаты надо отобразить
   const paymentType = useGetPaymentType();
   // Получаем элементы типа оплаты
   const getElements: PayForm = useGetPayTypeFormElements(paymentType); 

   /* код идет дальше как-то это все рендерить */
}

Статья достаточно подробно рассказывает, как разделить и верстку и логику. На самом деле итоговая имплементация в статье другая, не как у меня в блоке выше, т.к. я сильно упростил ситуацию. Но сама реализация не так важна (кстати, там все сделано через контексты), важен сам паттерн: вместо размазывания фичи по switch case следует обобщить код, а потом предоставить несколько реализаций для этого кода

https://commerce.nearform.com/blog/2024/tale-of-a-refactor/

#development #javascript #react #refactoring

Method Shorthand Syntax Considered Harmful

Небольшая статья про то, что TypeScript некорректно проверяет методы структуру, объявленные через shorthand синтаксис.

Объявим структуру Dog

interface Dog {
  barkAt(dog: Dog): void;
}

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

interface SmallDog extends Dog {
  whimper: () => void;
}

Теперь объявим собаку, которая умеет гавкать на маленьких собак

const brian: Dog = {
  barkAt(smallDog: SmallDog) {
    smallDog.whimper();
  },
};

Т.к. каждая маленькая собака (SmallDog) является собакой (Dog), то все выглядит легально.

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

const normalDog: Dog = {
  barkAt() {},
};
brian.barkAt(normalDog); // runtime error here!

Почему так происходит? Я бы объяснил это так: Typescript проверяет метод в brian на совместимость к интерфейсу, но далее в проверке не использует эти знания и считает что brian соответствует интерфейсу Dog. Т.е. по хорошему TS не должен считать расширение типа аргумента совместимым относительно оригинального типа.

Исправляется это через отказ от использования shorthand синтаксиса для объявления методов

interface Dog {
  barkAt: (dog: Dog) => void;
}

interface SmallDog extends Dog {
  whimper: () => void;
}

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

Это ошибка, которая может выстрелить в любом проекте т.к. держать такие нюансы постоянно в голове невозможно. Поэтому есть правило
Eslint-правило @typescript-eslint/method-signature-style, запрещающее такие объявления методов.

Для тех кто дочитал до конца пасхалка. Если перейти от этой статьи к списку всех статей, то рядом будет про то, когда необходим тайпкаст в as never. Короткое, но занимательное чтиво про то, как выстрелить себе в ногу.

https://www.totaltypescript.com/method-shorthand-syntax-considered-harmful

#development #typescript #methodShorthand

Towards Qwik 2.0: Lighter, Faster, Better

Команда разработки Qwik готовит релиз 2 версии фреймворка. Qwik использует концепцию Virtual Dom для работы, поэтому есть проблема восстановления Virtual Dom исходя из HTML разметки после серверного рендера. В данной статье описывается изменение решения этой проблемы во второй версии qwik, которое улучшает перформанс-метрики приложения

Если коротко, то в текущей реализации qwik ставит комментарии в HTML, а также использует кастомные атрибуты

<div q:container="paused" q:render="static-ssr" q:version="dev" q:base="/build/" q:locale q:manifest-hash="dev">
  <main>
    <!--qv q:s q:sref=5 q:key=-->
      <!--qv q:id=7 q:key=xYL1:zl_0-->
        <!--qv q:key=H1_0-->
          Count: 
          <!--t=8-->123<!---->! 
          <button on:click="..." q:id="9">
            +1
          </button>
        <!--/qv-->
      <!--/qv-->
    <!--/qv-->
  </main>
  <script type="qwik/json">{...}</script>
</div>

В новом qwik HTML-комментарии исчезнут, что делает верстку намного чище.

<div q:container="paused" q:render="static-ssr" q:version="dev" 
     q:base="/build/" q:locale q:manifest-hash="dev">
  <main>
   Count: 123!
   <button on:click="...">+1</button>
  </main>
  <script type="qwik/state">[...]</script>
  <script type="qwik/vnode">!{{HDB1}}</script>
</div>

Тем не менее, qwik'у нужна информацию, которая была в комментариях. Эту информацию переместили в отдельный <script type="qwik/vnode"> в конце документа. При этом информация записывается в специальном формате и есть даже разбор нотации для компонента

Код компонента для верстки выше выглядит вот так:

<main>
  <Counter>
    <>
      {'Count: '}
      {signal.value}
      {'!'}
      <button on:click="...">+1</button>
    </>
  </Counter>
</main>

Информация о его виртуальных нодах выглядит следующим образом !{{HDB1}}. Это расшифровывается вот так:
- ! описывает сколько элементов надо скипнуть до <main>
- { - <main> имеет виртуальный элемент
- { - еще 1 виртуальный элемент <>
- H - H - это 7 буква алфавита (начиная с 0), поэтому из Count: 123 мы берем первые 7 символов и получаем виртуальную ноду Count:
- D - D - это 3 буква алфавита (начиная с 0), следующая текстовая нода 123
- B - это 1, поэтому следующая нода !
- 1 - описывает количество элементов, которые надо просто использовать. В нашем случае это button

Выглядит одновременно элегантно и жутко, но, очевидно, что такая нотация очень компактна.

Также виртуальные ноды станут ленивыми и будут более эффективно использовать память. Ноды будут использовать массивы вместо объектов, лениво инициализироваться, а также переиспользовать DOM-ноды

https://www.builder.io/blog/qwik-2-coming-soon

#development #qwik #javascript

Дайджест за 2024-02-12 - 2024-02-16

Top Front-End Tools Of 2023
Список лучших frontend-инструментов 2023-го года. Список большой и содержит всякое разное: UI-библиотеки, инструменты для CSS, AI-инструменты, инструмент для 3D-моделирования на CSS, шаблонизатор писем и многое другое. Что-то конкретно выделять не хочу, но, я думаю, каждый найдет в этом списке что-то для себя


How to Detect Clicks Anywhere on a Page in React
Небольшая заметка про то, как трекать любой клик в рамках страницы в React. Для многих описанное в статье не будет откровением (спойлер: обработчик вешается на body), но в статье есть интересный кусок с добавлением условной логики в глобальный обработчик на основе условия "является ли событие - событием из формы". Для меня стало открытием, что у любого события есть метод composedPath, который позволяет определить, через какие элементы проходило событие.

Tale of a Refactor
Неплохая статья про рефакторинг кодовой базы. Прочитав название статьи, я думал, что это про реальный кейс крупного рефакторинга. Но, оказалось, что это не так. Автор рассказывает на простом примере, как с помощью рефакторинга упростить код фичи, при этом получив возможность добавлять новые под-фичи без правок в уже существующие под-фичи

Простой пример в статье: это форма оплаты. Изначально она содержит 1 тип оплаты, а затем появляются еще 2 типа оплаты. Естественно, логично предположить, что могут появиться еще новые типы оплаты.

В комментариях к посту в канале мнения на счет статьи разделились: кому-то рефакторинг понравился, кому-то показалось, что стало только хуже

Method Shorthand Syntax Considered Harmful
Небольшая статья про то, что TypeScript некорректно проверяет методы структуру, объявленные через shorthand синтаксис.

Towards Qwik 2.0: Lighter, Faster, Better
Команда разработки Qwik готовит релиз 2 версии фреймворка. Qwik использует концепцию Virtual Dom для работы, поэтому есть проблема восстановления Virtual Dom исходя из HTML разметки после серверного рендера. В данной статье описывается изменение решения этой проблемы во второй версии qwik, которое улучшает перформанс-метрики приложения

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

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

Union, intersection, difference, and more are coming to JavaScript Sets

В Set добавляют новые методы (и вроде они уже есть в новом Chrome): union, intersection, difference, symmetricDifference, isSubsetOf, isSupersetOf и isDisjointFrom.

В целом, названия говорят сами за себя:
- setA.union(setB) - создает новый Set со всеми значениями из setA и setB (объединение множеств)
- setA.intersection(setB) - создает новый Set со значениями, который есть и в setA и в setB (пересечение множеств)
- setA.difference(setB) - создает новый Set со значениями, который есть в setA, но нету в setB
- setA.symmetricDifference(setB) - создает новый Set со значениями, которые есть только в одном из двух сетов
- setA.isSubsetOf(setB) - вернет true, если все значения setA есть в setB (А - подмножество Б)
- setA.isSupersetOf(setB) - вернет true, если все значения setB есть в setA (А - надмножество Б)
- setA.isDisjointFrom(setB) - вернет true, если ни одного значения в setA нет среди значений setB (множества не пересекаются)

https://www.sonarsource.com/blog/union-intersection-difference-javascript-sets/

#development #javascript #set