Why I Chose to Modularize the Ducks in My React App // Lauren Lee // CascadiaJS 2018

React and Redux are awesome but the state management can be overwhelming for beginners. This talk is all about how to keep your code DRY, scalable, and maintainable- the dream trifecta!- regardless of its size and scope. Creating “ducks”, or modularized components, allows you to keep all of your state in one place and avoid creating a new file for every single action and reducer. This talk will cover how to create those ducks!

[tomson]

Information about Ducks start at 16:00

[Xxpr]

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.

[ilyapyatin]

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?