Structure by functionality instead of technical type

[alber70g]

Is there any particular reason to structure the app based on technical properties of a file instead of functional properties? I can imagine that when a project grows in size the mental burden to switch contexts between 4 directories can be limiting. Any chance this could be in a functional way?

Looking through the app I see the following technical separation: components, constants, containers, models and stores. I'd like to look at a directory structure and see what and where the functionalities are. Right now it's unclear.

I'd suggest the following separation/structure:

• App: this is where the components Footer and Header reside, with the constants stores, the container Root and the createStore plumbing stuff. Here you do the wiring of actions creating stores, bootstrapping of the application, routing (with RouterStore), etc.
• Todo: should contain the TodoStore, the TodoModel, the ToDo components (TodoItem, TodoList, TodoTextInput)

This way, when the app gets more functionality, it's all neatly organized and you don't get in the way of other components, and you don't need to keep 4 directories open in when adding functionality.

Especially this structure allows for horizontal scaling instead of vertical scaling. More features only means more directories that can hold that specific feature. You can look at it as a tree: it either grows very tall with no branches (and it's going to be hard to pick the top most fruit) or have a tree with branches to the side. Each branch offering it's fruits just within reach.

[rokoroku]

Thank you for your interest!

This is really common concern in modern web app frameworks (e.g. vuejs, reactjs, ...) , and there is an answer from React.

• Pick any of the above approaches (or come up with your own) and start writing code! You’ll likely want to rethink it anyway after you’ve written some real code
• Eventually it will grow large enough that you will want to separate some files from the rest. By that time you’ll have enough knowledge to tell which files you edit together most often. In general, it is a good idea to keep files that often change together close to each other. This principle is called “colocation”.
• https://reactjs.org/docs/faq-structure.html

I've grouped files by its type in this repo since it'd be better to know the components' role and responsibility for those who are looking for a starter example.

But as you might know, there is no strict rule for file structure. So don't think too much about this repository's folder structure seriously :)

[Inlesco]

@rokoroku I'd propose to close this one as it's not an "Issue" really and provides very little benefit being attributed to "Issues" at this present moment.