О, спасибо! Да можно без декораторов. Из его примеров:

class Doubler {
 value = observable(1)

 double = computed(function () {
   return this.field * 2
 })

 increment = action(function () {
   this.value++
 })

 constructor() {
   initializeObservables(this)
 }
}

Выглядит норм, хотя, не очень здорово с this. Но жить можно.

Это прям очень радостно слышать)
Контрибьютить более чем нужно!

Вообще в реатом очень много чего пришло не от меня, за что всем участникам большое спасибо) Я сам все время опаздываю что-то делать…

Отлично!

Я вот смотрю, можно ли приделать что-то типа https://github.com/microsoft/tsdoc, чтобы на основании JSDoc-комментариев из кода автоматически генерить  документацию к API (в билд-скрипте). Что скажешь?

Можно и ручками генерить доки, но опыт показывает, что тогда дока всегда будет отставать от кода. А JSDoc-комментарии ещё можно линтить, и тогда они гарантированно будут правильными

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

В итоге, я за то что бы описывать альтернативы в каком-то отдельном месте доки (гайды, например) - это прям надо, а вот добавлять что-то в core - это всегда большой вопрос.

Можно не деструктерировать результат useActions 🙂
Но вообще это тоже спорный вариант, нужно еще подумать

P.S. не useActions, а перегрузка useAction (ох как я люблю перегрузки)

reatom/immer 🙂

о, как раз возникал вопрос зачем там массив

Есть вероятность что в 6ой версии поменьше будет

Бест-практики - это отлично. Но dispatch-то - это ж базовая штука, которая во всех примерах есть. И она же часть best practices, или нет?
Но вообще, вопрос у меня возник в связи с переходом с redux, и, может быть, useStore должен пойти в @reatom/redux-compat

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

В TS декораторы тоже экспериментальные, формально)

Я вовсе не хотел настаивать, чтобы всё шло в core-пакет. Но вот наработанные, стандартные уже функции хорошо бы иметь не в gist и на плейграундах, а в пакетах, и в git

О, точно

В теории прикольно, но на практике достаточно сложно делать, боюсь

Я смотрел фьючерсы - там для моего мозга не очень всё просто пока. Но даже на reatom 1.1, по-моему, можно поэкспериментировать с реактивностью

@reatom/redux-compat - а вот это прям хорошая идея, думал над этим.

Я на выходных займусь

В доке, в первую очередь.