Небольшие апдейты по докам:

Продвинутый пример написания собственного оператора (withReadyAtom)

withInit с несколькими примерами

Небольшой интерактив, высскажите, пожалуйста, свое мнение :)

В первом реатоме стейты автоматически чистились после всех отписок. Сейчас это выглядело бы как onDisconnect(anAtom, anAtom.reset) вообще на всех атомах. Это было удобно в большей части кейсов, но не удобно и не явно в некоторых запутанных кейсах, когда есть быстре ремаунты одного или разных компонентов использующих один и тот же атом. Возможно, было бы практичнее повесить ьна эту механику дебаунс и это решило часть проблем.

Что вы об этом думаете? Как вы менеджите актуальность ваших стейтов? Кажется, самый популярный паттер - фабрика, инстанциирующаяся в useMemo родительского компонента или контекста. Решение лучше - атомизация сразу при получении данных извне (при получении новых данных - пересоздаем инстансы). Еще лучше - computed factory.

А вы какими паттернами пользуетесь? Вам чего-то не хватает?

Автоматическая инвалидация ресурса

reatomResource удобен для описания асинхронных данных зависящих от локальных состояний (фильтров \ урла). Но что на счет инвалидации при обновлении удаленного ресурса?

Например, у нас есть список элементов, и кнопка удаления элемента, как описать рефетч ресурса при успешном выполнении экшена удаления?

Самый простой способ - внутрь самого deleteThing после авейта апишки вставить thingsResource(ctx).

Это хороший способ, но не всегда он является элегантным, особенно если deleteThing создается кодгеном и подлезть в его исходники невозможно. Конечно, на такой случай у нас есть onCall и вы можете написать deleteThing.onFulfill.onCall(thingsResource). С хуками вы можете дизайнить любые ваши состояния и экшены как бы замкнутыми и изолированными, но с возможностью навесить дополнительную логику сверху, при необходимости. Прелести композиционных примитивов ?

Но эту задачу можно решитьь еще лучше!

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

Напомню, от горячего onChange стоит отказываться в пользую ленивого reaction!

А что же с onCall? Это мелкая обертка над onChange, а action - обертка на atom гарантирующая временность стейта вызова (params и payload). Поэтому его так же можно заменить на spy! Когда вы спаите экшен (обычный или из reatomAsync - не важно), реатом подписывает текущий компьютед на вызов этого экшена. Поэтому, что бы подписать инвалидацию ресурса на какой-то экшен, достаточно сделать так.

```
const thingsResource = reatomResource(async (ctx) => {
ctx.spy(deleteThing.onFulfill)

const params = ctx.spy(thingsParamsAtom)
return ctx.schedule(() => fetch(...params))
}, 'thingsResource').pipe(withDataAtom([]))
```

И у этого подхода есть преимущества над onCall. Если удаление случиться прямо с таблицы которая сейчас отображается (ctx.spy(thingsResource.dataAtom)) - рефетч будет вызван сразу после окончания промиса на удаление. Но если вы зашли в карточку элемента и там выполнили удаление, рефетч случиться только когда пользователь вернется на страницу со списком элементов, потому что spy ленивый и на карточке элемента ресурс не используется (карточка должна фетчиться отдельным экшеном / ресурсом).

Ой что это у нас ~~в 4 утра~~ год спустя вылезло : https://www.reatom.dev/package/effects/#reaction

reatomResource - реактивное получение данных. reaction - реактивное отправление данных. Ну типа.

Реакция должна заменить onChange в коде логики (для утилит ещё нужна будет), потому что сейчас это:
1) Еще один способ сделать одно и тоже.
2) Делает код более менее линейным.
3) Не очевидно работает на компьютедах.
4) Совсем странный код получается при необходимости обрабатывать несколько источников (см. мотивацию https://www.reatom.dev/package/async/#reatomresource).

Reatom

effects

Reatom for effects

withVariables

В чате спросили как сделать оптимистик апдейт аналогично тенстаку: https://tanstack.com/query/latest/docs/framework/react/guides/optimistic-updates#via-the-ui

Держите простой оператор withVariables который к асинк апдейту (мутации) добавляет соответствующий атом variables.

```

import { AsyncAction, atom, Atom, withAssign, withComputed } from "@reatom/framework"

export type WithVariables = T & {
variables: Atom[1]>
}
export const withVariables = (
initState: State,
): ((anAction: T) => WithVariables) =>
withAssign((target, name) => ({
variables: atom(initState, ${name}.variables).pipe(
withComputed((ctx, state = initState) => {
ctx.spy(target).forEach(({ params }) => {
state = params[0]
})
ctx.spy(target.onSettle).forEach(() => {
state = initState
})

}))

```

Обратите внимание, что апдейт атома variables ленивый, если на него может не быть подписки, но его все равно нужно обновлять - добавьте пару onCall на соответствующие экшены, как рассказано тут: https://t.me/reatom_ru_news/249

Список основных изменений в v4, релиз планируется в течении пары месяцев:
https://github.com/artalar/reatom/issues/841

Есть изменения, миграцию которых можно автоматизировать кодмодом (раз, два), эти задачи пока ни на кого не назначены, если хотите вписаться в контрибьюшен - эти задачи не должны быть сложны (можно взять какой-нибудь https://github.com/coderaiser/putout)

GitHub

v4 · Issue #841 · artalar/reatom

The upcoming version "4" will feature several changes, but most will be straightforward to migrate. Here is the list of main changes. Publish only an ESM bundle. Store all code in a singl...

https://fxtwitter.com/artalar_dev/status/1790289615850475742

Ментейнер RXJS в твиттере пытается доказать что только с обсерваблами можно “просто” решить проблему конкурентных асинхронных процессов и приводит код (“просто”, Карл?!). На самом деле это не так, конечно же.

https://www.reatom.dev/package/effects/#concurrent

X (formerly Twitter)

artalar (@artalar_dev) on X

@BenLesh With observables things looks much more complex https://t.co/CF964WNxzl

В @reatom/npm\[email protected] была добавлена более агресивная политика следования аборт контроллеру контекста в reatomComponent, который привязан к анмаунту компонента. Это позволило подсветить более явно проблему с реализацией создания и следованию контроллера - если у вас перестали работать экшены с включенным StrictMode - это оно.
Как выяснилось реакт может анмаунтить, а потом маунтить обратно компоненты НЕ сбрасывая их стейт. на этот случай была добавлена проверка и пересоздание контроллера при необходимости.
Пожалуйста, обновитесь до @reatom/npm\[email protected]. effects / framework пакеты тоже желательно обновить, были внесены небольшие фиксы эдж-кейсов.

Разбор настоящего и будущего reatomLinkedList - хелпер для супер-оптимальной работы со списками любого размера.
https://youtu.be/W2B_dtFEfcI

YouTube

Инкрементальные вычисления на примере reatomLinkedList

Материалы по теме: - код примера: https://github.com/artalar/reatom/tree/v3/examples/reatom-jsx - https://signia.tldraw.dev/docs/incremental - https://portal.gitnation.org/contents/beyond-virtual-lists-how-to-render-100k-items-with-100s-of-updatessec-in…