Having used both Redux and Vuex, personally, I prefer Vuex a lot more. Vuex has a similar "Duck" format, however, you can also namespace it as a module, have submodules, call actions of another namespaced module, call root actions etc etc.
But what if we have 10-15+ actions and a corresponding reducer with 200-300+ lines of code (I've seen those), plus what about selectors? We would end up with a really big file and I'd say it's clear that we don't want it. Generally it's more convinient to work with a bunch of small files instead of one big file (I think Robert Martin mentions that in his "Clean Code" book). Plus this naming "Ducks", at first I thought the presentation will be about something related to ducktyping. Why do we call a module a "duck"? Do we have to contain all reducers, actions etc. in one file to consider it a module? Can't it be a folder?
I don't know why it is called ducks, but here is where I first read about this pattern github.com/erikras/ducks-modular-redux and now I've been using this ducks like patterns for 2 years. If you are not into large files, It is probably better to collect feature related reducer, actions etc. into a single folder and maybe export all the folders content from the index file. IMO this patterns does not require the kind of mental context switching, what I experience with the traditional redux file structure.
If you have a reducer with 200-300 LOC, the problem is there. You have said it: is better to work with a lot of small files. So first of all, to being able to work with ducks, you must have to decouple your logic to the point were everything you will be changing or creating, needs to be a very small piece of logic.
I would agree with the comment. In my experience redux action files and reducer files tend to get bigger as the application grows and hence it would not be very feasible to combine them into the same file. We could have the smaller ones all in the same file and larger ones split into their own files but having to remember which was which will add to the cognitive load as well. I once read somewhere, I think Medium, of a rather interesting thought. We use redux to basically notify the UI when data was updated and we do that when both local and remote state changes. The idea was to use only the db as the source of truth. With something like GraphQL you respond early and store expected results into the local cache and update the UI. I've not yet tried this but sounds interesting to me.
Information about Ducks start at 16:00
Having used both Redux and Vuex, personally, I prefer Vuex a lot more. Vuex has a similar "Duck" format, however, you can also namespace it as a module, have submodules, call actions of another namespaced module, call root actions etc etc.
But what if we have 10-15+ actions and a corresponding reducer with 200-300+ lines of code (I've seen those), plus what about selectors? We would end up with a really big file and I'd say it's clear that we don't want it. Generally it's more convinient to work with a bunch of small files instead of one big file (I think Robert Martin mentions that in his "Clean Code" book). Plus this naming "Ducks", at first I thought the presentation will be about something related to ducktyping. Why do we call a module a "duck"? Do we have to contain all reducers, actions etc. in one file to consider it a module? Can't it be a folder?
I don't know why it is called ducks, but here is where I first read about this pattern github.com/erikras/ducks-modular-redux and now I've been using this ducks like patterns for 2 years.
If you are not into large files, It is probably better to collect feature related reducer, actions etc. into a single folder and maybe export all the folders content from the index file. IMO this patterns does not require the kind of mental context switching, what I experience with the traditional redux file structure.
If you have a reducer with 200-300 LOC, the problem is there. You have said it: is better to work with a lot of small files. So first of all, to being able to work with ducks, you must have to decouple your logic to the point were everything you will be changing or creating, needs to be a very small piece of logic.
I would agree with the comment. In my experience redux action files and reducer files tend to get bigger as the application grows and hence it would not be very feasible to combine them into the same file.
We could have the smaller ones all in the same file and larger ones split into their own files but having to remember which was which will add to the cognitive load as well.
I once read somewhere, I think Medium, of a rather interesting thought. We use redux to basically notify the UI when data was updated and we do that when both local and remote state changes. The idea was to use only the db as the source of truth. With something like GraphQL you respond early and store expected results into the local cache and update the UI.
I've not yet tried this but sounds interesting to me.