Часто бывают ситуации, когда в React-приложении уже не хватает возможностей стандартного React Context + useState, но тянуть какой-то сторонний стейт-менеджер желания (и главное большой необходимости) нет. В статье ниже, реализован очень хороший пример своего легкого, удобного и расширяемого стора:

➡️ https://blog.bitsrc.io/streamlining-state-management-in-react-with-a-plugin-based-architecture-48aa9ba04abc

Внизу данной статьи приведены ссылки на самые популярные на сегодня стейт-менеджеры. От себя еще добавлю в список Jotai - нечто среднее между Zustard и Recoil. Он легковесный и простой в понимании:

https://jotai.org/

#react

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

Архитектура приложения:

✅ eslint-plugin-boundaries
Гибкий и удобный плагин, для ограничения импорта элементов системы в соответсвии с задеваемыми настройками. Поможет держать организацию папок/файлов проекта под контролем. Возможностей много, настраивать можно как удобно на свой вкус и цвет.

Дополнительные плагины для архитектуры приложение с узким применением:
https://www.npmjs.com/package/eslint-plugin-hexagonal-architecture
https://www.npmjs.com/package/eslint-plugin-relations

Строгость кода:

✅ eslint-plugin-sonarjs
Плагин, помогающий определить потенциально плохие участки кода. Правил много, не со всеми обязательно соглашаться, но основная часть будет очень полезна для чистоты проекта.

Красота кода:

✅ Prettier + eslint-plugin-prettier (смотрите секцию Recommended Configuration для настройки с ESLint)

Избавляет от извечного холивара по поводу стилистика кода. Да, правил для кастомизации стилизации не сказать, что много, но их достаточно, чтобы код выглядел красиво и единообразно. Крайне желательно настраивать с пре-коммитом через husky + lint-staged, чтобы в репозиторий всегда улетал отформатированный код.

Самая простая конфигурация:

.husky/pre-commit:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged

package.json:

{
"lint-staged": {
"*.{js,jsx,ts,tsx}": [
"eslint --fix",
"git add"
]
}
}

✅ eslint-plugin-import + @typescript-eslint/consistent-type-imports + sort-imports

Превращает бесформенную массу импортов в упорядоченный список.

Пример конфигурации, которую использую в своих проектах:

.eslintrs.js

{
rules: {
'@typescript-eslint/consistent-type-imports': 'error', // нужно для разделения на import и import type. Подробнее зачем вообще import/export type тут: https://stackoverflow.com/a/64243357
'sort-imports': [ // упорядочивает импортируемые значения. Подробнее тут: https://eslint.org/docs/latest/rules/sort-imports
'error',
{
ignoreDeclarationSort: true,
allowSeparatedGroups: true
}
],
'import/first': 'off', // отключено, т.к. правило перезатирается "import/order" ниже
'import/order': [ // собственно сортировка импортов, которая мне нравится
'error',
{
alphabetize: {
order: 'asc'
},
groups: [
['builtin', 'external'],
'internal',
['parent', 'object'],
['sibling', 'index'],
'type'
],
'newlines-between': 'always'
}
]
}
}

✅ @cspell/eslint-plugin
Красивый код - это еще и грамматически верно написанный, поэтому проверка правописания необходима. Плагин в этом поможет. Можно добавить свой whitelist для специфичных слов. Есть минус - крайне сильно негативно влияет на скорость проверки ESLint, поэтому есть смысл вынести только на уровень CI и исправлять грамматически ошибки уже после CI-пробежки.

Пример базовой конфигурации для CI:

.eslintrs.js

const eslintConfiguration = {
// настройки
}

if (process.env.NODE_ENV === 'production') {
eslintConfiguration.overrides.push({
files: ['src/**/*'], // список файлов для проверки правописания
excludedFiles: ['src/**/*.stories.ts'], // исключения
plugins: ['@cspell'],
rules: {
'@cspell/spellchecker': [
'error',
{
customWordListFile: './spellcheck-whitelist.dict' // файл с исключениями. Имеет специальный формат. Побробнее тут: https://cspell.org/docs/dictionaries-custom/
}
]
}
});
}

return eslintConfiguration;

✅ Stylelint
Не джаваскриптом едины - стилизация и структуризация нужны и для CSS. Stylelint поддерживает поддерживает как сам CSS, так и CSS-подобные (например, SASS/LESS), так же CSS-in-JS (например, styled-components, emotion). Заводится не без приключений, но оно того определенно стоит.

#javascript #typescript #eslint

От сидячей работы спина часто начинает побаливать и доставлять дискомфорт. Ниже простой рецепт для снятия напряжения (да и руки крепче будут 😀):

➡️ https://youtube.com/shorts/PNFvCw3uygY

Довольно старая, но всё еще актуальная статья про ошибку десятилетий - null:

➡️ https://www.lucidchart.com/techblog/2015/08/31/the-worst-mistake-of-computer-science/

Решение проблемы с null/undefined тоже приложено к статье. Если лень читать, то решение заключается в использовании специальной Maybe-монады или ее аналогов для не ФП-ориентированных языков (больше информации, что такое монада с примером Maybe на вики). Maybe выступает в роли обертки над значением, которое может быть null/undefined. Фактически мы объявляем новый тип, который может иметь реальное значение, либо его не будет. В относительно современных языках отдельного значения null может и отсутствовать как такового, например, как в Rust, Zig, Swift и т.д, и там как раз используется данный прием с Maybe (может называться по другому, например Option в Rust, но суть та же).

Касательно JS/TS, то, как по мне, то подход с Maybe сложно-применим, особенно с его введением в уже существующий проект. Да, помогает избавится от некоторых проблем, но это за счет существенного увеличения порога вхождения в проекта, т.к нужно изучать функциональных подход к решению задач. Для TS задачу проверки на null и undefined можно переложить на сам язык через конфигурацию:

tsconfig.json:
strictNullChecks: true (а лучше strict: true в целом)
noUncheckedIndexedAccess: true

Но если же ваш проект изначально использует (или вы планируете использовать) библиотеки с ФП-парадигмой такие как rxjs (из коробки фронтовый Angular и бекендовский Nestjs хорошо дружат с rxjs), ramda, lodash/fp или прям fp-ts, то подход выше может отлично вписаться

#general #fp

Ниже очень подробная статья по популярным npm-модулям для создания интерактивных консольных утилит и их раскраски:

➡️ https://blog.kilpatrick.cloud/posts/node-cli-app-packages/

Еще подкину в список https://lars-waechter.gitbook.io/voici.js/ для форматирования консольных таблиц

#cli #nodejs

Достаточно подробный гайд от DataDog про то, как оптимизировать ресурсы окружения в Kubernetes, а соотвественно и финансовые расходы:

➡️ https://www.datadoghq.com/blog/rightsize-kubernetes-workloads/

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

#kubernetes

За что мы любим дизайнеров:

Вышла новая мажорная версия node.js 20. В статье описаны основные значительные изменения и новые фичи:

Доступна серверная JavaScript-платформа Node.js 20.0 https://opennet.ru/58998/

Отличный набор статей по React Router:

➡️ https://www.robinwieruch.de/categories/react-router-6/

Закрывает насущные вопросы по использованию библиотеки:
- Вложенный роутинг
- Аутентификация и приватные роуты
- Правильный редирект
- Основные хуки
- Ленивая подгрузка через React.Suspense

#react

Базовое, но четкое, пояснение разницы между Message-Driven, Event-Driven и Streaming, т.к зачастую понятия путаются между собой:

➡️ https://www.alibabacloud.com/blog/an-analysis-of-the-basic-concept-of-message-driven-event-driven-and-streaming_599521

Так же в конце статьи приложены варианты специфицирования вашего событийного API. Для nestjs есть модуль nestjs-asyncapi для AsyncAPI

#general #event

Хорошая подборка библиотек для карт на React и JavaScript в целом:

➡️ https://javascript.plainenglish.io/5-javascript-mapping-libraries-when-to-use-them-961ff6366d0b

От себя:
Доводилось использовать только Leaflet - отличная библиотека, удобная в использовании и богатая по функционалу. Но из подборки впечатлила react-map-gl - обязательно попробую

Немного о «мультипоточности» в node.js. Хорошая статья рассказывающая про основы worker_threads с примерами высокоуровневых оберток:

➡️ https://snyk.io/blog/node-js-multithreading-worker-threads-pros-cons/

От себя:
В node.js «настоящих» потоков вы не найдете, как не ищи. Но это ни плохо, ни хорошо - просто сам движок не подразумевает оных. Если нужно реальное распараллеливание на уровне ОС, то в конце статьи как раз приведены примеры популярных языков с их поддержкой: Java, C/C++, Rust и еще десятки аля C#, Go, Closure, Haskell и т.д.

Вообще, если интересно разобраться с процессами/потоками, то неплохая базовая статья с картинками ➡️ https://dev.to/kwereutosu/multi-threading-and-parallel-programming-1l9m

Твоя команда: закрываете проект раньше дедлайна, заказчик максимально доволен
Твоё начальство:

С 16й версии node.js добавили новый модуль node:test (stable с 20й версии). Название говорящее - модуль предназначен для написания тестов со стандартным набором функций, который можно найти в любом известном аналогичном модуле как mocha, chai, jest и т.д. Поэтому необходимость таких модулей фактически сводиться на нет.

Статья ниже про создание своего кастомного тест-репортера для node:test:

➡️ https://www.nearform.com/blog/writing-a-node-js-test-reporter/

#nodejs