а почему нельзя в первом скрине так же сделать?

На мой взгляд на счёт того, чтобы сделать как в mobx - есть одно концептуальное отличие. Реатом - это синглстор, а mobx по идее мультистор. И условно атом в mobx имеет своё состояние, а в реатоме атом имеет состояние только в контексте стора. В следствии чего нельзя просто вызвать атом atom() и получить значение и поэтому нужна функция трекинга. С другой стороны в целом можно было бы реализовать что-то подобное как в mobx, но тогда это будет ещё один mobx и возникает вопрос - а зачем ещё один mobx?

Есть очень классный cellx, если бандсайз мобыкса не подходит

Какую же атомарность не поддерживает mobx? Речь о том что после того как компютед-атом выбросит ошибку то будет неконсистентность в приложении (например какие-то атомы уже пересчитались с новым значением а какие-то нет) ? Ну ок, и что ты предлагаешь делать? Прежде всего выбрасывание ошибки в computed-атоме это баг приложения и такого быть не должно потому что computed должен быть чистой функцией (так как это просто derived-state). Я в этом случае поставил бы враппер который отсылал ошибку в sentry и полностью перезагружал бы страницу после отображения попапа с ошибкой.
Ок, допустим страницу перезагружать неудобно и хочется пометить отдельный компонент как ошибочный но при этом сохранить консистентность остального состояния. Тогда я не вижу что мешает вместо перезагрузки страницы сбросить состояние всех computed-атомов в случае ошибки через какой-нибудь враппер поверх создания computed()-атомов в мобиксе. То есть hoc поверх компонента через try-catch детектит ошибку компютед-атома а дальше он сбрасывает (или пересоздает) все компютед атомы которые есть в приложении и вызывает перерендер всего приложения. Тогда компютед-атомы снова пересчитаются а компонент который затрекал ошибку будет теперь отображать view-ошибки вместо чтения ошибочного компютед-атома и тот уже не будет вызываться и не будет выбрасывать ошибку

Потому что компонент должен подписаться на атом и тут либо hoc который будет трекать обращения через вызов как atom() либо хук вроде useAtom(atom). А инлайнить вызов хука в шаблоне (<div>{useAtom(atom)} </div>) нельзя потому что как только эта запись будет внутри условного рендера то сразу появится баги потому что не сохраняется последовательность вызова реакт-хуков между рендерами. Вот и получается что хуки нужно выносить в начало компонента а это создает "double declaration problem"

полностью перезагружал бы страницу

- это очень плохой паттерн, нужно всегда стараться сохранить последний валидный стейт, отображаемый пользователю, потому что там могут быть важные для него данные (которые он сам внес или до которых он не сразу дошел, типа 15 страница в таблице после 5+ фильтров)

сбросить состояние всех computed-атомов через какой-нибудь враппер

- вот я предполагаю что это поведение по умолчанию, поэтому делаю как делаю

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

https://codesandbox.io/s/reatom2-todo-example-yo4oy

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

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

Поясню для проходящих мимо: это не имеет оверхеда по перфу, в плане зависимости от количества элементов.

это получается можно подписаться напрямую на отдельный элемент в списке?

да

Только если нужно куда-то передать данные, третьему сервису / компоненту, нужно либо их заранее отмапить, либо проксей обернуть, которая по гету будет getState делать

Новый реатом - планируется другая либа, или мажорный релиз? Где почитать про изменения?)

Мажор, альфа второй версии уже в паблике

доков пока нет
нужно еще много протестировать

Спасибо, тогда можно и исходники глянуть)

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

Я очень постарался сделать их простыми)