Open bcolloran opened 5 years ago
I think it would indeed be nice if the actions/reducers/component logic was a little closer together for each feature. I find myself using project search to navigate between files more often than I'd like to admit -- it would be much more convenient if things were closer together in the filesystem so I could use the directory sidebar in atom more easily (since like would be close to like spatially).
The feature example you linked to makes the most initial sense to me -- the reducks approach seems weird, though I'm sure I would get used to it. Doing up a prototype for discussion sounds good.
just wanted to put together an issue to track the idea @hamilton proposed last week: right now, our files are mostly split up by function -- components, reducers, actions, etc -- but this makes it hard to know what is in scope when you are working with only one slice of the app.
some references:
organizing by feature: https://marmelab.com/blog/2015/12/17/react-directory-structure.html -- seems fine. i'd be open to putting tests at the top level rather than in a
__test__
subfolder if folks think that is useful. i see the author's point that it makes it easier to see what stuff needs testing, but it is also kind of clutter, so i'm ambivalent. i'd default to no change unless someone is specifically taken by the idea.the "ducks"/"reducks" approach seems popular: https://github.com/erikras/ducks-modular-redux and https://github.com/alexnm/re-ducks . There are other variants too. i really like the idea of kind of name-spacing redux actions per feature/concept as e.g "my-app/widgets/LOAD". I think that would be quite clarifying. we could adapt one of those patterns by also moving the relevant bits of state schema. my hunch is that something based on the folder-oriented "reducks" pattern will scale better.
maybe i'll do a draft PR organizing some feature to see what an option could look like, just for discussion. maybe the console would be good since i was just working on that.
@hamilton @wlach @mdboom @openjck more ideas and reading materials very welcome! :-)