Angular Architecture

The repository includes specialized folders for advanced topics. To run these, navigate to the specific folder and follow the standard npm install and ng serve process.

State Management Demos

• State - DIY Store: Located in state-management/diy-store. Starts with a simple "do it yourself" store using subjects and observables.
• State - NgRx: Located in state-management/ngrx.
• State - ngrx-data: Located in state-management/ngrx-data.
• State - Observable Store: Located in state-management/observable-store using the Observable Store library.

Other Specialized Demos

• Cloning: Located in the cloning folder.
• Input/Output Properties: Located in the input-output-demo project.
• Shared Library: Located in the shared-library-example project.

The Standalone Lab serves as a reference for converting an Angular application from an NgModule-based architecture to a Standalone architecture.

There are two versions of this lab:

1. REFERENCE version: Represents the 100% NgModule state of the application. It is a near-perfect copy of the routing-guards-and-preload-strategies END state.
2. END state: The final state of the lab after the conversion to Standalone components and configurations has been completed.

The demos folder contains several core architectural examples:

• Communication: Demonstrates using services and subjects for component communication.
• Component Inheritance: Shows how to implement component inheritance.
• Features Modules: Demonstrates application structure using NgModules.
• Http Client RxJS: Shows how to use RxJS operators to combine HTTP client results.
• Pipes and Functions: Demonstrates the use of Angular Pipes.
• Signals: A simple demonstration of Angular Signals.
• Structuring Components: Focuses on component presentation and change detection.
• Subjects: Demonstrates the different types of RxJS Subjects.
• View Models: Provides progressive examples of implementing view models.
• Planning: Provides architectural planning tips.

When using PreloadAllModules, a CanActivate guard only prevents the user from navigating to a route in the UI. However, because the module was preloaded, the network chunk for that module will still be downloaded.

To prevent the code chunk from loading entirely, you must prevent the module from being preloaded or use a different strategy that intercepts the loading process before the chunk is requested.

NgRx is a reactive state management library for Angular based on several core concepts that work together to manage application state:

• Actions: Objects that represent unique events (e.g., GetCustomers, AddCustomer). They carry a type and can optionally include a payload (data).
• Reducers: Pure functions that receive the current state and an action, then return a new state. They are responsible for updating the data store.
• Effects: Side-effect handlers (e.g., for HTTP calls) that listen for actions, perform tasks, and then dispatch new actions (like Success or Error actions) based on the result.
• Selectors: Functions used to retrieve and slice specific pieces of data from the store. They allow components to react to changes in the state.
• Store: The single source of truth that holds the application state.

If you want to prevent a lazy-loaded module from being downloaded at all when a user attempts to navigate to a route, use the canMatch property instead of canActivate. While canActivate allows the chunk to load before checking permissions, canMatch allows the router to skip the route (and its associated module loading) entirely if the guard returns false.

// In AppRoutingModule
{ path: 'villains', loadChildren: () => import('./villains/villains.module').then(m => m.VillainsModule), canMatch: [AuthGuard] }

When implementing component communication via services, choose the appropriate RxJS Subject type based on the required data emission behavior:

• Subject: Sends data to subscribed observers. Any data emitted before a subscription is made is not sent to that observer.
• BehaviorSubject: Sends the last emitted data value to observers immediately upon subscription.
• ReplaySubject: Sends all previously sent data to new observers (the number of buffered values can be configured).
• AsyncSubject: Emits only the last value to observers, and only when the sequence is completed.

Preload strategies allow you to load JavaScript bundles in the background before a user explicitly navigates to a route. You can configure these in your AppRoutingModule using different strategies:

PreloadAllModules

Loads all lazy-loaded modules immediately after the initial application load.

PreloadSelectedModulesList

An opt-in strategy where only specific modules are preloaded. To use this, add data: { preload: true } to the specific route configuration you wish to preload.

NetworkAwarePreloadStrategy

A strategy that checks the user's connection speed. It only preloads modules if the network connection meets certain criteria (e.g., faster than 3G).

// Example: Opt-in Preload Strategy configuration
{ path: 'villains', loadChildren: () => import('./villains.module').then(m => m.VillainsModule), data: { preload: true } }

You can prevent users from accessing specific routes by implementing a CanActivate guard.

1. Generate a service-based guard using the Angular CLI: ng generate guard AuthGuard (select CanActivate).
2. Implement the logic within the guard to return false when access should be denied.
3. Register the guard in your AppRoutingModule by adding it to the canActivate array of the target route and ensuring it is provided in the module configuration.

// Example implementation logic
export const authGuard: CanActivateFn = (route, state) => {
  return false; // Prevents navigation
};