🎯 Introduction

A page (or view) module is a module that represents a page or a view of an application. It is a collection of related components, directives, pipes, and services, routes and other page modules (sub-pages) that work together to form a cohesive user interface.
Page modules serve the purpose of organizing and encapsulating a page's functionality. They are the first component rendered after a user lands on a specific route defined in our app routing module, simplifying the management and maintenance of the page.

@Injectable()
export class PreloadModulesStrategy implements PreloadingStrategy {
    preload(route: Route, load: () => Observable<any>){
        if (route.data && route.data.preload) {
            return load();
        }
        return of(null);
    }
}

I almost always use lazy loading for my entry page modules, which results in a smaller entry file bundle and faster loading times. Additionally, I recommend a custom preload module strategy, allowing me to specify which pages I want to fetch over the network when app is initially loaded (so they will be fetched even if user didn't land on the specific route). This ensures that the modules are loaded quicker when accessed by the user later.

Quick example in my little app shows how JS chunks for Home and Movie pages are loaded and ready to use when application is loaded, while Settings page JS chunk is loaded after user has navigated to it.

🎯 Page Module Content

Page module also contains collection of components, services (http services, resolvers, guards, etc..) and all of the other Angular building blocks specific for that page that goes under the same starting route.

It also contains routing (sub-routes) definitions relative to page module path defined in app-routing.module.ts which means it will also contain other Page modules.

We are currently grappling with an ongoing issue of determining the most suitable level of nesting for our subpages. While it may seem intuitive to arrange our folders based on our routing definitions, I can attest that this can quickly become unwieldy and result in excessively nested files, which can be frustrating to navigate and runs counter to our primary goal of simplifying the folder structure.

So, my proposition is that we put all of the subpages into a single folder labeled "modules". Additionally, it is my recommendation that we place all components intended for use in the page module and its sub-modules in a folder titled "components", even if they are only utilized within a specific subpage.

🎯 Example

I will use this awesome page TheMovieDB as a reference for my example of setting up folder structure and routing:

I hope that folder structure is self-explanatory.

• shell (contain all of the components used for _hosting page sub modules that may share some repeatable layout like menus)_
• modules (contain all of the modules referenced in movie.module.ts in this case)
• components (contain all of the components used across any module - shared or not)
• services (contain all of the movie services)
• ... etc

The main objective is to ensure effortless access and customization of our codebase by simplifying the directory hierarchy and keeping it flatten as possible.