[Spike] Enforce a stronger directory structure in Redux state

[dottorblaster]

Part 1: alternatives on the table

Since an architectural decision about where to put what was needed on the Redux-state-side-of-things, I took a bit of time to research on what we could do.

Alternatives taken into account were:

• Feature files that contain slices/reducers living side by side with components
• Rails-style: separate folders for “actions”, “constants”, “reducers”, “containers”, and “components”
• Ducks/slices, so actions, constants, and reducers living altogether in the same file into the state package

I personally found Rails-style really compelling but we are using redux-toolkit that is very opinionated towards ducks/slices, since we are using the createSlice helper that automatically generates constants and action creators.

Part 2: execution

Since ducks/slices is what we could be most comfortable with, I tried to just get rid of the current actions directory bringing related actions inside the dedicated files that contain the slices.

We now have:

• The root directory with slices, constants and actions. Optionally we can move all the slices to a slices subdirectory.
• Sagas are separate from the global state shape and live under the sagas subdirectory.
• Selectors follow the same pattern. Since selectors can aggregate data coming from multiple source slices, they live in a selectors subdirectory.

Part 3: drawbacks of this approach

We have one drawback: action creators related to sagas now live along with slices and action creators generated by redux-toolkit. I found reasonable to have action creators all stuffed in one specific place, but I understand that it might not be the case for everyone.

Proposed directory structure

assets/js
├── app.js
├── common
│   ├── Banners
│   ├── Button
│   │   ├── Button.js
│   │   ├── Button.stories.js
│   │   ├── Button.test.js
│   │   └── index.js
│   ├── ListView
│   ├── Modal
│   ├── ObjectTree
│   ├── Table
│   ├── Tags
│   └── Tooltip
├── pages
│   ├── AboutPage
│   ├── ChecksCatalog
│   ├── ClusterDetails
│   ├── DatabaseDetails
│   ├── DatabasesOverview
│   ├── ExecutionResults
│   ├── Health
│   ├── HealthSummary
│   ├── Home
│   └── HostDetails
├── hooks
├── lib
├── state
│   ├── sagas
│   │   ├── clusters.js
│   │   ├── clusters.test.js
│   │   └── index.js
│   ├── selectors
│   │   ├── clusters.js
│   │   ├── clusters.test.js
│   │   └── index.js
│   ├── clusters.js
│   ├── clusters.test.js
└── trento.jsx

[dottorblaster]

(This is only a non-working draft, if we decide we like this we can finalize the refactoring)

[arbulu89]

As far as I understand the feature or ducks/slices would require more changes, as it puts the component code in the same "domain" folder.
So I see this more like:

src/
    features/
        hosts/
            Hosts.jsx
            hostsSlices.js
        clusters/
             Clusters.jsx
             clustersSlices.js

If we still continue with a separated components folder, we would be in a really middle-grounded setup. We should even add the specific saga and selectors code in those folders.

Otherwise the code is not split by domain (which this structure expects).
I see the current example still much more closer from the ruby-on-rails way.

[dottorblaster]

@arbulu89 yes you're right. I have worked long time with the ducks pattern and it's basically tying reducers, actions and constants all into the same file. Redux' documentation states something more 😅

Anyway: yes I never tried Rails and @fabriziosestito told me the same, that the structure we could move to is very similar to that. My main proposal is that we keep the state directory enforcing the ducks pattern for slices, then we will have a common directory for the single components of the design system and a pages directory for the controller components that architect the single page view. How do you feel about that? I enriched my first message with an example of a potential directory tree.

[nelsonkopliku]

Even if I am biased towards features/domains, I find the proposed directory structure reasonable. Good job!

When we have the agreement let's just plan accordingly. Are you thinking of a one big refactor or a gradual one?