Ducks Structure

[hnordt]

I would like to share my Ducks Structure. It worked very well for my apps in production.

1. I follow all Ducks guidelines, except for including my app name in actionType
2. I don't create one Duck for each app module, instead I create one Duck for each app action, that way when an app action needs more complexity, it can grow and yet is easy to reason about because it's isolated

(I meant to post it on ducks-modular-redux repo, I'm sorry)

[whatifif]

Thanks for sharing this. Separating the reducer into each action seems good for maintenance.

As for the action type, it seems that attaching a domain or app name at the front as shown in Ducks guideline may be useful to avoid the possible name-conflict with other developers' in future.

[tearsofphoenix]

agree with @whatifif .

[grifx]

I'm against coupling an action with a reducer. Therefor, in my opinion ducks is an anti-pattern. Coupling an action with a reducer assumes the action is only used by only one reducer. An action can be used by many reducers and that's the beauty of redux. In fact, actions are consumed by each reducer of your app.

Yes it's convenient to have your actions and "their" reducer in the same file. This convenience is ephemeral. Quickly you'll have actions used by many reducers. It didn't scale well in my application.

[jaraquistain]

@grifx what structure did you find scaled better within your application? I'd love to see your reducer and file structure as I'm trying to decide what pattern I think best fits what I'm working on.

@hnordt do you combine your reducers together with reduce-reducers?

[tearsofphoenix]

Maybe like this: https://github.com/mxstbr/react-boilerplate/tree/master/js separate actions, constants, reducers into different folders.

[grifx]

@jaraquistain I just put in two different files the actions and the reducer. Right now I'm doing something similar to what @tearsofphoenix suggested but my constants are in my actions files and the actions and "their" reducer are in the same folder, which isn't good.

It makes sens to have a constant folder but I don't know if there is a substantial gain.

I would suggest you to do this:

• actions
  • commands: Used to change the state of the server. They can be used on every pages. There should be no tight coupling with the view models. You only send the data that is required and the server shouldn't return any data, only a http status code. Here the Client should respect the server interface.
  • productCommands.js: createProduct({id: uuid.generate(), name: 'Iphone'}), removeProduct(productId), assignCategoryToProduct(productId, categoryId), unassignCategory(productId, categoryId)
  • queries: Used to fetch data from the server. High coupling with the components. The shape of the data should fit perfectly with you components. Here the server is supposed to respect the client interface. Action creators name starts usually with fetch* or load*
  • homePageQueries.js: fetchDashboard()
  • productSearchPageQueries.js fetchProductSearchResult(name, {page, limit})
  • productDetailsPageQueries.js fetchProductDetails(slug)
  • shared: Used across the whole application
    • autoCompleteQueries.js: loadProductAutoComplete(), loadBrandAutoComplete(), loadCategoryAutoComplete(),
    • userActions: loadUserDataFromSession()
• reducers: You should have one reducer per view, or collection of views
  • homePageReducer.js
  • mainNavBarReducer.js:
  • ProductSearchPageReducer.js:
  • SingleProductPageReducer.js
  • shared: You can have reducer factories.

Tell me what you think.