Possibly refactor the project structure?
ASteinheiser opened this issue · comments
I think, if this project is to scale, the structure will need to change. Whether that be a little or a lot, I'm not sure.
At a minimum I want to move some of the modules to a better location. Some of them belong co-located with the component that uses them.
Here's @JoniTech 's suggestion:
"When you plan to scale, divide by functionality instead, as in monsters / world / maps. Kind of how you structured your reduces(src/features) now."
Sorry if I was unclear, that recommendation was more for an enterprise level app. They tend to grow so fast you have to consider splitting them up, so dividing by functionality makes sense.
I would recommend the technical structure for this project, mirroring the default structures you see in example and boilerplate apps.
@JoniTech So are you saying something like a components / containers / redux folder setup?
Yes, but do what works for you.
This is quite a self-contained app, so it's unlikely parts of it would get pulled out for any reason (like reuse). The divide by functionality might make it harder to find things.
The technical structure should make your life easier in maintaining and improving it.
I feel like I'm currently using a structure that is close to the normal technical structure, but I felt the need to call "containers" -> "features" since that is closer to what they are doing.
I'm not totally sold on doing the normal components / containers / redux setup, but I'm open to hearing justification for it or other suggestions for project structure.
After much refactoring on the refactor/code-cleanup branch, I think I found that I just needed to move all my loose action functions into an actions folder associated with each feature.
So we have:
components: re-usable UI elements
config: constants and redux store setup
data: json objects for items, monsters, and maps
features: essentially just React containers with a reducer and actions
modules: helper functions shared across app
I feel like this is basically the same as the components / containers / redux setup, but just a little more tuned for this use case.
Do you have any additional thoughts @JoniTech ?
It's a small project. As long as you can easily find your way around the code-base this structure is fine.
I still think features and modules are a bit off. You might want to change modules to utils or helpers, depending on their function. Those are more common in React projects in my experience.
And features maybe containers, if that's what they are.
Gotcha. I think utils instead of modules makes more sense.
The features are both a container and redux store though. I think I am pleased with the structure after changing modules -> utils and moving all the redux actions logic into their appropriate spot.
Going to close this general issue. I'll be merging in the refactor soon. If anyone has any specific things they want to refactor, create a new issue.