Bun v0.3.0

Вышел Bun 0.3.0.

Пока что Bun достаточно быстро развивается и приносит новые интересные фичи.

В релизе 0.3.0 было уделено много внимания перформансу и потреблению памяти. Теперь Bun под нагрузкой кушает в разы меньше памяти (30МБ против 146МБ в 0.2.2). Также, по их собственным бенчмаркам, аналогичный код в Node.js и Deno кушает 71 и 91 МБ соответственно. Предлагаю и дальше относится к бенчмаркам Bun как к маркетинговой истории, но отмечаю, что работу по уменьшению потребления памяти они все же проделали.

Также в релизе:
- улучшено форматирование console.log
- енкодирование текста ускорено в 3 раза
- добавлены еще фичи для совместимости с node.js
- Bun автоматически устанавливает пакет из npm при вызове import. Пакеты устанавливаются в глобальный кеш, пост инсталл скрипты не запускаются
- Появился FileSystemRouter. Т.е. теперь можно описывать роутинг к хендлерам на уровне путей в файловой системы. Как, например, в next.js. Собственно там и есть такой параметр style: "nextjs"
- Также появилась возможность считывать ввод консоли через async итератор. Выглядит это весьма интересно

for await (const line of console) {
  console.log("Received:", line);
}

https://bun.sh/blog/bun-v0.3.0

#development #bun

A Gentler, Better Way to Change Minds

Как изменить мнение человека по какому-то вопросу? Часто случается, что люди расходятся во мнениях и они пытаются изменить мнение опонента по вопросу. Однако тактика переубеждения в споре работает далеко не всегда - как правило все остаются на своём.

Статья помогает разобраться, почему так, и как по-другому подходить к изменению мнения человека по какому-то вопросу.

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

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

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

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

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

Как же все таки подходить к коммуникациям когда мнения расходятся?

1. Не разделяйтесь на "мы" и "они". Это провоцирует разделение, в том числе психологическое. Будьте в одном круге коммуникации чтобы слышать мнения друг друга.
2. Не принимайте возражения персонально. Помните, что возражения к вашему мнения - это не атака лично на вас.
3. Слушайте. Исследования говорят, что слушание более эффективно чем разговор в плане изменения мнения другого человека. Внимательное слушание с задаванием хороших вопросов работает намного эффективнее, чем разговор. Спор же, согласно тем же исследованиям, особо не влияет на мнение других людей по вопросу.

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

https://www.theatlantic.com/family/archive/2022/04/arguing-with-someone-different-values/629495/

#managment #changeManagment #softSkills

Всех с наступающим новым годом 🥳 (а кого то уже с наступившим)

В этом году канал сильно вырос и превратился из совсем крошечного клуба любителей читать краткое описание ссылок в малоизвестный канал с небольшой, но крутой аудиторией. Спасибо вам! Вы даете хороший фидбек (если честно, обожаю когда вы оставляете комментарии под постами - поправляете меня, или заносите новый контекст, или обсуждаете топик, а также комментарии с благодарностями - они помогают мне не забывать, что недостаточно просто постить ссылки - нужно также давать и собственную оценку материала), мотивируете меня делать более качественные описания статей, а также читать эти самые статьи. Без вас, дорогие подписчики, я бы читал, вероятнее всего, реже 🙃

Благодаря вашему фидбеку, в канале появились еженедельные дайджесты (иногда у мнея даже появляется мысль, что многим только дайджесты и нужны 😬 но коментарии под постами говорят, что есть достаточно людей, которые читают в риалтайме и даже оставляют комментарии).

Также, благодаря фидбеку, я планирую немного подразобрать все старые ссылки и подкорректировать там тэги и, возможно, сформировать какой-то список must have read по определенным темам.

Планы на новогодние выходные:
- Я постараюсь найти контент для канала. Возможно пойдет аудио или видео контент т.к. теперь будет время посмотреть что-нибудь из беклога докладов\подкастов
- Следующий дайджест выйдет 9го января и будет содержать все новости начиная с последней декабрьской недели
- Возможно выйдет несколько материалов от меня

Спасибо вам еще раз ❤️ и еще раз с новым годом 🎉

Guiding principle: Speed generates quality

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

Однако на самом деле выбор стоит между быстро и качественно и некачественно. Скорость генерирует качество, а не ухудшает его.

Как это работает?
Статья начинается с притчи про мастера гончарного дела. Он разделил учеников на 2 группы: первая группа оценивается по тому, сколько вещей они произведут, а вторая группа оценивается по качеству того, что они произведут. Когда пришло время оценить работу групп, то оказалась, что первая группа сделала 50 первоклассных горшков, 40 хороших горшков и так далее. Вторая же группа сделала всего 1 первоклассный горшок.

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

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

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

При этом надо отличать "делать быстро всякую ерунду" и "делать быстро маленькими шагами". В фразе "Speed generates quality" cкорость - это прежде всего про маленькие итерации и процесс обучения. А процесс обучения ведет к качеству.

https://jchyip.medium.com/guiding-principle-speed-generates-quality-f0672db3e4bc

#managment #agile #feedbackLoop #quality #recommended

⚛️ Applying Design Patterns in React: Strategy Pattern

Статья про применение шаблонов проектирования в React.

Это хорошая обучающая статья, описывающая, как проблема Shotgun Surgery (хирургия дробовиком?) решается с помощью паттерна Стратегия.

Что такое Shothub Surgery - это когда 1 фича "расплескивается" на кучу файлов, и когда приходит время что-то в ней изменить, необходимо сделать изменения в куче файлов разом.

В статье есть конкретный пример - это карточка цены на продукт (base, pro, premium уровни), в которой ценообразование располагается везде разом. Это нарушает принипы S и O из SOLID.

Чтобы решить эту проблему, предлагается использовать паттерн Стратегия. В данном случае мы можем инкапсулировать всю логику, связанную с ценообразованием и тарифами в отдельный класс и его уже предоставлять компонентам. Тогда компоненты будут отвязаны от тарифов, а все изменения по тарифам будут теперь делаться только в реализации Стратегии.

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

В общем, хорошая обучающая статья про хорошие практики.

https://dev.to/itshugo/applying-design-patterns-in-react-strategy-pattern-enn

#development #react #designPatterns #recommended

GlitchTip

GlitchTip - опенсорсный аналог Sentry. Вплоть до совметимости с API sentry, что позволяет легко перейти с sentry на glitchtip.
В чем основная фича и Sentry и GlitchTip: они предоставляют из себя системы трекинга ошибок приложения. Т.е. вы подключаете систему через SDK к приложению, а затем можете отправлять туда ошибки. Система же умеет:
- Показывать конкретную строчку кода в репозитории, которое привело к ошибке, а также отображать полный стак-трейс
- Показывать действия, которые перед этим делал пользователь. Для веб-приложений обычно собирается инфа о сетевых запросах и действиях пользователя. Также можно настроить кастомные "хлебные крошки", например, выводить исполненные redux события
- Показывать, в каком релизе или коммите впервые появилась данная ошибка

Короче, если использовать с умом, то такие системы очень мощные. Хорошо, что появляются опен-сорсные альтернативы.

https://glitchtip.com/

#development #monitoring #glitchtip

GlitchTip вместо Sentry. Как мы бесплатно настроили мониторинг ошибок

В продолжение предыдущей ссылки: статья на хабре, про то как и почему компания, DevOps из компании Constanta решили взять GlitchTip вместо Sentry.
Статья очень короткая и в целом сводится к следующему:
- GlitchTip не хуже Sentry
- GlitchTip потребляет меньше ресурсрв
- GlitchTip проще деплоить и сопровождать

К сожалению подробностей реального использования не рассказывается. А было бы интересно про это почитать (насколько легко исследовать ошибки, какую держит нагрузку и тд и тп)

https://habr.com/ru/company/constanta/blog/706386/

#development #glitchtip #monitoring

Одна платформа, чтобы править всеми

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

Что описано в статье:

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

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

Также, платформа предоставляет командам удобный API для создания сервисов и БД. Вы хотите запустить новый микросервис? Выбери язык, потыкайся в настройки и платформа сгенерирует тебе кучу базового кода. Нужна постгря? Нажми еще пару кнопок и будет у тебя свой инстанс БД.

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

Еще в статье много внимания уделено своей реализации service mesh.

В общем, очень объемная и достаточно неплохая статья про роль платформенной команды в большой компании. Есть много вариантов, что может делать платформенная команда и как помогать разработке. И вот Ozon поделился своим опытом использования паттерна "Платформенная Команда".

https://habr.com/ru/company/ozontech/blog/708274/

#development #paas #platformTeam #ozon

Дайджест за 2022-12-26 - 2023-01-06

Tao of Node - Design, Architecture & Best Practices | Alex Kondov - Software Engineer
Тао of Node - opinionated список бест практиксов для разработы сервисов на node.js.

Большинство практик действительно несут объективную пользу. Остальные являются скорее выбором автора среди альтернатив (поэтому список и opinionated).

React Bricks: React CMS with Visual editing for Next.js, Gatsby, Remix
React Bricks - CMS для Next.js, Gatsby, Remix.

Какую проблему решает React Bricks? Допустим, у вас есть создатели контента, которые не являются разработчиками. Они делают, например, лендинги или статьи в блог. Сейчас вам нужно решать, какой удобный инструмент им дать и как с ним интегрироваться. Вы, скорее всего, увеличите технологический стек, возможно завендорлочитесь на каокй-то инструмент, и не будете иметь достаточно контроля над ним.

Avoid These Common Pitfalls Of React useState
Статья про самые распространенные проблемы при использовании useState в react. В статье каждой проблеме приводится подробное описание в структуре:
- Пример кода
- Почему это проблема
- Как исправить

Bun v0.3.0
Вышел Bun 0.3.0.

Пока что Bun достаточно быстро развивается и приносит новые интересные фичи.

В обсуждении к посту в канале есть подписчик, который игрался с Bun

A Gentler, Better Way to Change Minds
Как изменить мнение человека по какому-то вопросу? Часто случается, что люди расходятся во мнениях и они пытаются изменить мнение опонента по вопросу. Однако тактика переубеждения в споре работает далеко не всегда - как правило все остаются на своём.

Статья помогает разобраться, почему так, и как по-другому подходить к изменению мнения человека по какому-то вопросу.

Guiding principle: Speed generates quality
Часто мы обсуждаем скорость и качество как противоположное. Типа надо выбрать или качество или скорость, но не оба вместе.

Однако на самом деле выбор стоит между быстро и качественно и некачественно. Скорость генерирует качество, а не ухудшает его.

⚛️ Applying Design Patterns in React: Strategy Pattern
Статья про применение шаблонов проектирования в React.

Это хорошая обучающая статья, описывающая, как проблема Shotgun Surgery (хирургия дробовиком?) решается с помощью паттерна Стратегия.

В обсуждении есть немного полезных комментариев

GlitchTip
GlitchTip - опенсорсный аналог Sentry. Вплоть до совметимости с API sentry, что позволяет легко перейти с sentry на glitchtip.
В чем основная фича и Sentry и GlitchTip: они предоставляют из себя системы трекинга ошибок приложения. Т.е. вы подключаете систему через SDK к приложению, а затем можете отправлять туда ошибки, где они представлены в удобном для «расследования» виде.

GlitchTip вместо Sentry. Как мы бесплатно настроили мониторинг ошибок

В продолжение предыдущей ссылки: статья на хабре, про то как и почему компания, DevOps из компании Constanta решили взять GlitchTip вместо Sentry.
Статья очень короткая и в целом сводится к следующему:
- GlitchTip не хуже Sentry
- GlitchTip потребляет меньше ресурсрв
- GlitchTip проще деплоить и сопровождать

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


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

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

Знакомство c Reatom

Статья от автора Reatom про Reatom. Это первая обучающая статья в серии статей про Reatom.

Статья очень короткая, но показывает основы Reatom:
- вокруг чего основная идея (сюрпрайз, атомы и реактивность)
- основное API для создания и изменения атомов

В комментариях засветились свидетели mobx и nin-jin (автор $mol)

Надеемся на продолжение серии статей. Контента в текущей, объективно, мало, чтобы понять что за зверь этот Reatom и стоит ли начать его использовать.

https://habr.com/ru/company/ruvds/blog/708826/

#development #reatom #javascript

Bun v0.4

Продолжаем следить за Bun, у которого вышел релиз 0.4

В этом релизе:
- bunx - аналог npx но в 100 раз быстрее
- флаг --bun позволяющий интерпретировать все вызовы nodejs через shebang (#! /usr/bin/env node) как вызовы Bun. Это делается через создание временного алиаса node = bun
- Добавлены хуки в инструментарий для тестирования

https://bun.sh/blog/bun-v0.4.0

#development #bun

React Native is not the future

Статья от команды разработки приложения Standard Notes про их борьбу с мультиплатформенностью с помощью React Native. Standard Notes - это приложение для ведения заметок. Достаточно хорошее даже.

У них изначально был небольшая команда разработки и три платформы - веб, который контейнизировался в электрон для публикации десктоп приложения, android и ios. В начале разработки, в 2016 году, приложения дла мобилок писали нативные. Но тут встала проблема поддержки трех платформ - сложно поддерживать паритет по фичам (это когда на всех платформах есть одинаковый набор функциональности) и работоспособности, когда у вас 3 разные кодовые базы. В 2017 году они переехали на React Native и это позволило иметь 2 кодовые базы весто трех. Изначально их все устраивало, но дальнейшая практика показала, что достичь паритета по фичам для веба и мобилки оказалось сложно.

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

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

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

https://blog.standardnotes.com/40921/react-native-is-not-the-future

#development #reactNative

Олег рассказывает про типичные проблемы и нюансы при использовании SSR и node.js. В обсуждении к посту есть интересные комментарии и ссылки.

Привет!

Давно хотел поделиться накопленным за последний год опытом оптимизаций и масштабирования SSR приложений.

Думал уложиться в несколько telegram постов, но меня немножечко прорвало, и получилась почти полноценная статья.

В статье расскажу про основные проблемы SSR (спойлер - React и Node.js) и рассмотрю ряд возможных оптимизаций:

- Static Site Generation
- Rendering at the Edge
- Микросервисы
- Оптимизациия кода
- Кэширование компонентов
- Кэширование запросов
- Rate Limiting
- Fallback кэш страниц
- Client-side rendering fallback
- Кластеризация и воркеры

Ссылка на статью в моем Notion - https://superoleg39.notion.site/SSR-04ad1ab46de346edb244a1112bd357a3

Очень жду ваш фидбек в комментарии)

Методология как конструктор: инструкция по сборке / Филипп Дельгядо

Достаточно старый, но популярный в определенных кругах, доклад от Филиппа Дельгядо про процессы разработки.

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

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

#managment #process #recommended

React ref Callback Use–Cases

Достаточно хорошая статья, разбирающая как и зачем использовать ref-колбеки для элементов в React/

В статье рассказываются основные юзкейсы, нюансы основы работы React с ref-колбеками и как эти нюансы можно использовать.

Разобранные юзкейсы:
- Вызов метода DOM-элемента при его вставке в DOM-дерево. Т.к. ref-колбек вызывается при вставке элемента в DOM, то этот колбек можно использовать для DOM-сайдэффектов типа "didMount". Например, ставить фокус или вызывать скрол.
- Получать данные о DOM-элементе
- Объяснено, почему, если хочется сохранить ref на элемент для дальнейшего доступа, лучше использовать useState, а не useRef. Тлдр: react не умеет следить за изменением ref, а значит использовать то, что хранится в ref в рендере - концептуально неправильно и небезопасно. В статье про это написано несколько экранов текста, я лишь очень утрировал
- Общий доступ к DOM-элементу

Если вам интересен React, рекомендую к прочтению. Лично я как-то не задумывался, что можно сразу в ref-колбеке делать нужную мне логику.

https://julesblom.com/writing/ref-callback-use-cases

#development #react #javascript #refs #recommended

Дайджест за 2023-01-09 - 2023-01-13

Знакомство c Reatom
Статья от автора Reatom про Reatom. Это первая обучающая статья в серии статей про Reatom.

Статья очень короткая, но показывает основы Reatom.

Bun v0.4
Продолжаем следить за Bun, у которого вышел релиз 0.4

В этом релизе:
- bunx - аналог npx но в 100 раз быстрее
- флаг --bun позволяющий интерпретировать все вызовы nodejs через shebang (#! /usr/bin/env node) как вызовы Bun. Это делается через создание временного алиаса node = bun
- Добавлены хуки в инструментарий для тестирования

React Native is not the future
Статья от команды разработки приложения Standard Notes про их борьбу с мультиплатформенностью с помощью React Native. Standard Notes - это приложение для ведения заметок. Достаточно хорошее даже.

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

Репост из канала SuperOleg dev notes
Олег рассказывает про типичные проблемы и нюансы при использовании SSR и node.js. В обсуждении к посту есть интересные комментарии и ссылки.

Методология как конструктор: инструкция по сборке / Филипп Дельгядо
Достаточно старый, но популярный в определенных кругах, доклад от Филиппа Дельгядо про процессы разработки.

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

React ref Callback Use–Cases
Достаточно хорошая статья, разбирающая как и зачем использовать ref-колбеки для элементов в React/

В статье рассказываются основные юзкейсы, нюансы основы работы React с ref-колбеками и как эти нюансы можно использовать.

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

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

A React Developer's First Take on Solid

Обзор фреймворка Solid с точки зрения React-разработчика.

Статья очень короткая, но показывает основную разницу между фреймворками:
- Solid построен вокруг реактивных сигналов. Solid запоминает как сигналы друг с другом связаны и строит на этом разные оптимизации. Например, может обновить конкретный DOM-элемент при изменении определенного сигнала
- в Solid JSX работает по-другому. Поэтому, например, для условий и циклов нужно использовать отдельные элементы
- Деструктурировать пропсы в начале компонента - антипаттерн (т.к. Solid отслеживает использование пропсов)

Также разобран аналог Next.js - Solid Start.

В общем, как обзор Solid.js - достаточно неплохая статья - коротко, объяснены ключевые моменты, даны ссылки для последующего чтения.

https://jakelazaroff.com/words/a-react-developers-first-take-on-solid/

#development #react #solidjs

Software Profession Resources

Трелло доска со ссылками на видео, статьи, книжки про всякое разное про разработку в общем и про процессы разработки

https://trello.com/b/1lfMkCOh/software-profession-resources

#development #recommended #links

Using Github Copilot for unit testing

В статье описывается, как с помощью Copilot писать юнит-тесты. Пример достаточно простой, но тем не менее выглядит впечатляюще.

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

https://www.strictmode.io/articles/using-github-copilot-for-testing

#development #testing #copilot

Structura.js

Structura.js - аналог immer, но в 22 раза быстрее (по бенчмаркам авторов) и только в окружениях, поддерживающих ES6.

Structura.js позволяет работать с имутабельными стейтами, используя при этом обычный мутирующий синтаксис.

Structura старается быть заменителем immer, поэтому используется аналогичный API для создания новых стейтов

const originalState = { 
  innerState: { test: true },  
  prop: false
}

const newState = produce(originalState, (draft) = {
    delete draft.prop;
    draft.newProp = true;
})

console.assert(originalState !== newState, "это разные состояния");
console.assert(originalState.innerState === newState.innerState, "innerState является пошаренным объектом для обоих стейтов");

В результате данного сниппета мы получим 2 разных объекта - newState и originalState, но которые при этом используют общее вложенное поле innerState. Т.к. мы знаем что innerState остался неизменным, то оба стейта просто ссылаются на один и тот же innerState. Эта фича называется structural sharing.

https://giusepperaso.github.io/structura.js/

#development #javascript #library #immutability #immer #structurajs