[Section] Scalable Application Structure

[piotrwitek]

Add a new section about how to create a scalable structure of your application.
This section should focus on goals:

• files grouped by features
• easy to add/remove features
• enable/disable feature on demand
• features should be reusable and pluggable across different redux applications

[Tauka]

Hello @piotrwitek, thank you for this guide and typesafe-actions lib

Have you heard of ducks for redux? I think it will work well for grouping by features, since if you slice store by features, there will be small number of actions for each slice, and they all can go into the same file (types, actions, side-effects, reducer, selectors)

Here is the example: https://gist.github.com/Tauka/15d35f36771d2512200bd9dc9b074807

Not insisting on anything, just a suggestion :) Don't feel obligated to consider it

[piotrwitek]

@Tauka Thanks for suggestion, it is really good!
I'll share with you some of my story working with "ducks" and then I'm open for discussion.
"Ducks" look cool and concise but unfortunately they introduce dependency mess which we "front-end developers" tend to forget about when using various bundlers.
If you would use some tool to generate dependency graph of your application (you can see some example I have created here), you would find it much harder to read what is happening on a high level, harder to test (because you have to mock everything), and you'd introduce cyclic dependencies as well which is the worst of them. Basically when you only want to import types or action creators you import all of your feature logic and implicit modules it depend on.
In case of your example look what you implicitly couple your dumb components to (and it will cascade and bring even more stuff from '../../helpers' and '../../redux' modules):

import { createActions, handleActions, combineActions } from "redux-actions";
import { call, put, takeLatest } from "redux-saga/effects";
import { api } from "../../helpers";
import { Root } from "../../redux";

So that's my story why I stopped using and recommending "ducks" in real big apps.

[piotrwitek]

Further analyzing of dependency patterns in redux feature-based architecture I can come up with:

• dumb components --> static-types
• smart components --> actions & selectors -> static-types
• store --> root reducer --> reducer --> actions -> static-types
• side-effects --> actions & selectors & services -> static-types
• services --> static-types

I would like to create a feature based architecture with the folder structure based on the above constrains, which I think that would promote loose implicit coupling.

[IssueHuntBot]

@BoostIO funded this issue with $50. Visit this issue on Issuehunt

[IssueHuntBot]

@issuehuntfest has funded $10.00 to this issue. See it on IssueHunt