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

А если вызвать два раза callAtom(bAtom) то хендлер-функция в атоме A оба раза запустится?

Высказала личное мнение. Хуки мне тоже не нравятся.

О, на правах офтопа, используешь композицию функций? Пишу хуки, стиснув зубы. Если используешь композицию, как типизируешь? можно пример в личку. А то я в тс чате спросил, сказали использовать хуки и не парится

У нас на проекте нет TS. Ну а насчёт композиций -- в основном использую ramda/pipe или ramda/compose + каррирование и частичное применение ( ramda/curry, ramda/partial )

Да, это тоже использовал вне ts среды. Вот только композиция плохо типизируется у рамды, приходится костылить

Сама не пробовала, но знаю что у https://remedajs.com должна быть хорошая поддержка TS из коробки

Не, тоже с композицией над реакт-компонентами плохо, надо зайти на второй заход, может не разобрался

Я на самом деле уже почти опустила руки и планирую в будущем уйти в ClojureScript с головой, в его экосистеме писать компоненты одно удовольствие

Реализация атома. memo занимается динамическим трекингом как раз

# перед номером атома как-то попроще и удобоваримее, имхо, будет

Мб вообще убрать? Там все равно скобочки

Кстати, displayName во второй версии же тоже можно вручную будет передать?

Пока, я думаю что нужно будет мутировать

const someAtom = declareAtom(…)
someAtom.displayName = `someAtom`

Пока, я думаю что нужно будет мутировать

const someAtom = declareAtom(…)
someAtom.displayName = `someAtom`

Ой, больно

Почему?)