Какова лучшая структура для приложения, использующего ngrx?

Структура 1

reducers
   index.ts //Combine all reducers
   user.reducer.ts
   product.reducer.ts
actions
   index.ts  //Combine all actions
   user.action.ts
   product.action.ts
effects
   index.ts //Combine all effects
   user.effect.ts
   product.effect.ts
selector
   //Combine all selectors
   user.selector.ts
   product.selector.ts

ИЛИ ЖЕ

user
  user.reducer.ts
  user.action.ts
  user.effect.ts
  user.selector.ts
product
  product.reducer.ts
  product.action.ts
  product.effect.ts
  product.selector.ts
reducers.ts //Combine all reducers
actions.ts //Combine all actions
effects.ts //Combine all effects
selectors.ts //Combine all selectors
 pd farhad21 июл. 2016 г., 10:58
Можете ли вы добавить еще несколько комментариев с вашим кодом
 Filip Lauc21 июл. 2016 г., 13:23
Мне лично нравится первый подход. Это структура, которую команда ngrx использует в своем примере приложения. Кроме того, у вас есть еще одна папка для интерфейсов или классов, и часто бывает, что вы используете один и тот же интерфейс более чем на одном редукторе. Вы также часто используете одни и те же действия для более чем одного эффекта и так далее. Вот почему я предпочитаю первую структуру.

Ответы на вопрос(2)

https://github.com/orizens/ngrx-styleguide

Второй способ, который вы упомянули, является лучшим, потому что (цитата из руководства по стилю):

ДЕЛАТЬ создавать отдельные файлы в каталоге редуктора для: редуктора, спецификации редуктора, действий редуктора и селекторов редуктора. Наконец, используйте index.ts в качестве бочки для экспорта содержимого каждого файла.Зачем? при разработке легче найти каждый соответствующий класс / файл

которая хорошо подходит для довольно небольшого приложения при использовании редукторов, действий или других элементов в нескольких компонентах SMART в приложении.

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

Обычно, работая с, т.е.user.reducer.ts, будет включать в себя работу с другими файлами: эффект, действия и т. д. Итак, второй подход кажется немного более аккуратным.

Я хотел бы предложить третью структуру, которая может подходить, и ту, которая следует подходу "баррель" в angular2:

- store
    - user
        - index.ts
        - user.actions.ts
        - user.effects.ts
        - user.reducer.ts
        - user.reducer.spec.ts

    // the store definition file - will expose reducer, actions etc..
    // for connecting those to the app in the bootstrap phase
    - index.ts

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

import { reducer as UserReducer } from '../store/user'; 
// or
import { UserReducer } from '../store/user' 

Я экспериментирую с этими подходами в своем приложении для медиаплеера с открытым исходным кодом.Echoes Player - http://github.com/orizens/echoes-player
Как уже упоминалось в другом комментарии, эти стратегии и архитектура, применяемые к эхо-плееру, скомпилированы вngrx styleguide

 chrismarx23 мая 2019 г., 00:08
Это структура по умолчанию при использовании начального набора схемы ngxs -github.com/ngxs/schematics
 Tuong Le25 июл. 2016 г., 08:35
Я тоже так думал.
 Michael 29 янв. 2018 г., 08:14
Я склоняюсь так же. Однако большая проблема с функциональным разделением (для меня) заключается в том, что некоторые функции зависят от других. Каждый раз, когда это происходит, я ломаю голову о том, как разделить их на самые чистые.

Ваш ответ на вопрос