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.