thomas-darling

Project structure for modular apps

The following represents a proven and scalable approach to structuring modular web apps. It is conceptually simple, relying on a few well defined structural patterns, some of which are repeated in a recursive fashion. A structure like this will often look much like the domain of the app, making it very easy to navigate, understand and reason about.

Naming conventions

All file and folder names must be lower case and the only word separator allowed is a single -. The only exceptions are tests, which must be named {name}.test.ts, and localized files, which must be named {name}.{locale}.{ext}.

In the following, - and + indicate expanded and collapsed folders, while ... denote additional unspecified items.

thomas-darling

Project structure for hierarchical apps

The following represents a proven and scalable approach to structuring hierarchical web apps. It is conceptually simple, relying on a few well defined structural patterns, repeated in a recursive fashion. A structure like this will often look much like the view hierarchy of the app itself, making it very easy to navigate, understand and reason about.

When deciding where to place something, always strive to place it as close to where it is used as possible, and then move it up in the structure only if it later becomes needed elsewhere. And if that does happen, always ask yourself whether you really need all of this, or only part of it. If the answer is the latter, you might want to consider refactoring, so only the relevant parts move up the structure, while the rest remains where it belongs, close to where it is needed.

A good test for whether the structure is in a good state, is to ask yourself "what would happen if I delete this module or component? What else wou