Реализация архитектуры Redux на MobX. Часть 1: «Проблемные места Redux»

Спасибо за статью. В предлагаемой на MobX архитектуре, хотя код в этой первой части и не приведен, прослеживаются некоторые спорные с моей точки зрения моменты:

1. Объединение store, actions (лучше их называть store modificators, чтобы не путать с редаксовыми) и selectors в единый слой. Те данные и методы, с которыми работают фронтендеры — не микросервисы и не игровые сущности, для которых группировка подходит четко, и Dog может run() и можно get condition() исходя из внутренних параметров. АПИ своего бэка или стороннее может быть так спроектировано, что содержит смешанные данные, которые придется разложить по десятку семантических сторов, поэтому фича редакса с возможностью по одной константе отлавливать payload в разных подсторах очень востребованна.
   Касательно селекторов — то же самое, часто необходима комбинация данных из нескольких семантических сторов, и get canShowSomeBlock не будет принадлежать ни стору User, ни UI, ни Forms, а данные, необходимые для вычисления данного параметра, могут браться из них всех. И тут на сцену выходит либо Dependency Injection со всей сопутствующей кашей и полным уничтожением семантичности и консистентности хранилищ, либо все же создается отдельный слой.
   Если же модификаторы и селекторы признать отдельным слоем и передавать в них весь store со свободой модификации и чтения данных из любого, то получаются простые для понимания и использования слои с собственной структурой, продиктованной не архитектурой хранилищ, а реальными вариантами использования. За счет передачи всего стора получается удобная группировка без необходимости в модификаторах делать ручные DI и вызывать многочисленные методы.
   Из недостатков описанного мной подхода — возможность раздувания этих функций-модификаторов хранилища, что решается более узкой их специализацией. Также многим, привыкшим к структурам типа Dog.run() не понравится отсутствие "явного разделения ответственности", когда функция может получать доступ к любому параметру без жестких ограничений, как и реактовые компоненты (через контекст) к любому экшену-модификатору или опять же параметру стора, что якобы дает разработчику "свободу действий", что обязательно выльется в лапшеобразный код с неявными взаимосвязями. На деле такое встречается намного чаще как раз при наличии ограничений, которые разнообразными хаками (DI, горизонтальные связи, параллельные системы доступа к данным, дубляж) преодолеваются и код становится не только лапшеобразным, но и неподдерживаемым — при желании его отрефакторить сломаться может что угодно. В случае же, если некий экшен, написанный юниором, использует данные из 4 подсторов сразу, хотя его можно было бы разбить на 2 более семантичных экшена, это рефакторится за минуты фактически без рисков поломки, и не является легаси, в отличие от хаков, обходящих основной архитектурный паттерн.

   
   

2. По поводу того, что в модификаторах не стоит вызывать асинхронную логику получения данных из сторонних источников. Тут, думаю, все же нужно подходить контекстуально — если данные юзера могут приходить только в одной ручке, то ничего плохого в том, чтобы написать

   
   

   const getUser = ({ store, api }) => {
       return api.getUser().then((user) => runInAction(() => {
           store.user = user;
       }));
   }

   
   

   я не вижу. Если же данные юзера могут приходить и в других ручках, то можно создать более универсальный модификатор setUser = user => partialAssign(store.user, user), но не считаю это обязательным изначально, так как выглядит преждевременной оптимизацией и в общем случае приведет к созданию десятков лишних функций.
   А сам сбор данных из сторонних источников в модификаторах считаю оправданным, так как иначе придется выделять еще один слой "подготовки данных перед вызовом модификатора", который всегда будет вызываться перед самим модификатором и в 99% случаев это будет дубляж. Оставшийся процент — кейсы, когда источником данных может служить не одна сторонняя система, а несколько, но это проще решить if условием в самом модификаторе, чем менеджерингом отдельного слоя предварительной нормализации данных. Либо можно таким вот promise-middleware паттерном

   
   

   const getMixedData = ({ actions, api }) => {
       return api.getDataWithPartialUser()
           .then(actions.setUser)
           .then(actions.setAnotherData)
   })

   
   

Признаю ошибку)