Follow ducks-like architecture

[dvdzkwsk]

I don't agree with the naming conventions, but overall it would be nice to group flux pieces together (constants/reducers/actions).

[justingreenberg]

agreed! i'm actually the one who initially restructured erik's universal example. i would propose something similar without the naming conventions (ie. namespacing constants for action types is unnecessary)

this is roughly how my projects are structured:

/redux
    /middleware
    /modules   [grouped redux logic aka "ducks"]
    /selectors [reselect helpers - probably not necessary for starter-kit]
    createStore.js

[dvdzkwsk]

Cool, I also really like the modules naming convention over ducks or whatever else. Thanks for the link, too; I'll probably do this refactoring tomorrow.

On an unrelated note, I've been thinking about switching away from the airbnb-config base to something closer to a mix of ract/standard. Any opinions on this? Biggest thing would probably just be removal of semi colons.

[justingreenberg]

:+1: rackt config

"space-before-function-paren": [ 2, { "anonymous": "always", "named": "never" } ]

are you gonna be ok with this rule tho? lol

[mtsr]

Removal of semi-colons still feels wrong to me. Call me a classicist :)

On 10 Dec 2015, at 23:51, David Zukowski notifications@github.com wrote:

Cool, I also really like the modules naming convention over ducks or whatever else. Thanks for the link, too.

On an unrelated note, I've been thinking about switching away from the airbnb-config base to something closer to a mix of ract/standard. Any opinions on this? Biggest thing would probably just be removal of semi colons.

— Reply to this email directly or view it on GitHub.

[dvdzkwsk]

@justingreenberg I will fight that rule until the day I die; it separates function definitions from invocations, and just makes the code look so much nicer.

@mtsr I was the same way until my new team forced it upon me haha. The other big debate now is "use trailing commas or not" or, if you're nuts like me, "leading commas?!"

[dvdzkwsk]

@justingreenberg could you offer up an explanation as to what exactly lives under /middleware? I thought it would be actual middleware (i.e. for the redux life cycle), but your comment about moving the DevTools component there threw me off.

[justingreenberg]

@davezuko i'm sorry i can see how that was confusing /middleware is totally for redux lifecycle stuff!

using the createDevtools HOC with monitors instantiates a container, but we still have to import it and invoke an instance method to inject the middleware hooks into the store. so it's not really a container, it's an enhancer for monitor components (which is why i proposed renaming to createDevTools.js or something less class-y)

maybe something like:

/redux
    /middleware
    /modules   [grouped redux logic aka "ducks"]
    /devtools/createDevToolsContainer.js
    /devtools/createDevToolsWindow.js
    createStore.js

seems more intuitive and puts some distance between project code and devtools

[dvdzkwsk]

Thanks for the explanation. I actually missed the fact in your previous comment that everything was nested within a redux folder... I'm not actually sold on that just yet, but I'm going to run out for a few minutes and mull it over. The big thing is that modules are now nested in e.g. ~/src/redux/modules/counter, so I might like to pull that up a level (~/src/modules/counter).

[justingreenberg]

@davezuko so the case for a redux folder is to establish a clearly defined boundary between state management and presentation, with the added benefit of (mostly) encapsulating redux integrations

i feel like many redux projects end up spreading out state logic between connected containers/components, devtools, etc. which is probably muscle memory from using flux with a bunch of stores... it ends up making things more difficult to reason about than they need to be with a single store.

since we're talking about using "ducks" (redux modules!!), that boundary is actually within reach. i experimented with some different project structures and this is what i ended up with...

./src
    /components
    /containers
        Root.js  # point of contact for devtools, code unchanged
    /layouts
    /routes
    /redux *
        /middleware
        /modules
            counter.js
        /helpers
            createDevToolsContainer.js
            createDevToolsWindow.js  # uses createDevToolsContainer.js
            createReducer.js
        configureStore.js
    /styles
    /views
    app.js  # point of contact for store / redux router
    index.html

the only points of contact between ./redux and the application are Root container (for devtools), any other connected containers, and app.js (an idiomatic redux app will pass action creators through props)