Recoil

Для начала, очень важно тот доклад посмотреть с React Europe, парень очень хорошо объясняет их кейс, очень интересно. Сразу нужно понимать, что у них эта штука работает очень эффективно потому, что их интерфейс это 90%+ UI state.

Я успел немного с либой поиграть, посмотреть чего может и чего пока нет.

Либу в твиттере часто пытаются прировнять к mobx или чему-то подобному реактивному, но в рекойл есть несколько особенностей, которые отличают либу от реактивности в mobx. Основное отличие от реактивности aka mobx (читай knockout) это то, что в recoil граф зависимостей ацикличный, можно делать только derived данные, никаких циклов быть не может. Второе важное отличие в том, что абсолютно нет никакого доступа к сеттерам в геттере.

Это убивает любую теоретическую возможность сделать “computed” который во время вычислений может сделать какой-то сайд эффект над другими атомами. Вот оно вроде как и “реактивно”, но по сути это просто derived state: максимально практичный, когда оно нужно, но без возможности сделать ерунду. С другой стороны, боюсь что кто-то может придумать здоровенный ацикличный граф просто потому что не сможет сразу связать данные, которые очень хочется связать. Хотя, рефакторить в таком случае не должно быть проблемой.

В целом, мне определенно нравится DX, може потому что оно мне сразу кликнуло в голове, так как уже подобное юзаю. Даже надеюсь что эту штуку больше начнут юзать, чисто из-за близости к обычному стейту. Особенно мне понравилось что useRecoilValue/useRecoilState ожидаемо заменяются друг другом независимо от того, что ты в них передаешь.

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

Одним из минусов вижу то что у атомов персистентное состояние. Если есть какие-то данные на скрине, которые нужно очищать, появятся костыли как в редаксе с сеттером/диспатчем во время загрузки страницы. Може команда ещё что-то сделает в этом плане, у них там, по их же словам, много ещё чего неясно до конца.

В случае асинхронных селекторов или атомов, под капотом нет никакого специального кеша, результат асинхронного геттера сохраняется персистентно. Сеттер у селектора не может менять значение самого селектора, разве что значения атомов, которые могут вызвать новый гет у селектора. Можно рассматривать это аналогично тому как data down events up работает в самом дереве реакта. Сейчас же получается что асинхронные селекторы это просто удобная форма для быстрого доступа к каким-то асинхронным данным. Очень круто что они сразу сделали её с саспенсом.

Я наверняка буду эту штуку использовать в случае если мне за пару часов нужно какую-то песочницу сделать с асинхронными данными или чем-то разбросанным по дереву. Атом или селектор объявить ещё проще чем сделать новый контекст с стейтом, при этом сложность проекта вообще не страдает от добавления новых атомов (про это хорошо в докладе описано).

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