Question about state/code duplication
izaleu opened this issue · comments
Hi, I'm a big fan of the re-ducks pattern and use it for all my React Redux projects. Unfortunately one issue I've run into is regarding code duplication. Each duck is supposed to contain all of the code it needs to work as a feature ... however I've noticed that there's the potential for a lot of code duplication across ducks which rely on the same state.
For example: imagine we have a duck A and a duck B which rely on the same property "systemLanguage". Ostensibly I should have separate actions, reducers, selectors and operations to handle this property in each duck, even though they are essentially referencing the same values. Within the duck the code for this property will be the same, which means any time I make a change to one duck, I'd have to change the other to keep their behavior in sync. Further, if I namespace the action types of each duck, a view component would need to dispatch two actions from two virtually identical action creators to keep the state of these ducks synced.
That doesn't sit right with me, so I've currently got another duck which is just for handling the kind of state that's shared between other ducks. It feels kind of gross to be reaching across the state object this way, but I'm not sure what else I should do.
The only other solution I thought of would be increasing the scope of what I consider a feature, but my concern then becomes that my duck will be gigantic: basically the entire app.
Any guidance on this issue would be appreciated.
Yes, that's a good question. Now keep in mind that I haven't worked with this in over a year now as I switched interests a bit. But glad to hear that it helped you.
As for the duplication problem this has always been my argument against the feature based split, because somehow in a growing app you will always have that shared/common that keeps growing out of the need to reuse. In 90% of the cases having a shared duck module worked in my experience. something like: applicationSettings or common. I wouldn't increase the scope of a duck, would rather keep it as small as possible, so that each reducer handles a very small slice of the big state.
The question is not specific to re-ducks, see https://stackoverflow.com/questions/42239302/accessing-a-part-of-reducer-state-from-one-reducer-within-another-reducer.
Reorganise your state to have a systemModule slice with systemLanguage property and have single reducer that can be triggered by different actions
This question is specific to re-ducks because your answer doesn't address the question of which duck the systemModule reducer belongs to. Also the shared duck I mentioned already manages that shared state in the same manner as described in that link, so... ¯_(ツ)_/¯. Gonna close this as @alexnm has answered sufficiently.