DEV Community: JesúsB

(Update: NgRx Signal Store Enhancements) Mastering State Management with NgRx Signal Store in Angular 🚀

JesúsB — Mon, 10 Feb 2025 10:33:56 +0000

With the recent updates to NgRx, several new features have been introduced that enhance the functionality and flexibility of the SignalStore. In this update, I will outline the key changes in the new code compared to the original implementation, along with explanations based on the updated NgRx documentation.

Key Changes and Additions

1. Introduction of `withProps`

The most notable change in the updated code is the use of the withProps feature. This allows us to define additional properties within the store, such as services or custom observables, making the store more modular and easier to manage.

Original Code:

withMethods((store, podcastService = inject(PodcastService)) => ({
  async getAllPodcasts() {
    patchState(store, { loading: true });
    const allPodcasts = await lastValueFrom(podcastService.getAll());
    patchState(store, { podcasts: allPodcasts, loading: false });
  },
}));

Updated Code:

withProps(() => ({
  podcastService: inject(PodcastService),
})),
  withMethods(({ podcastService, ...store }) => ({
    async getAllPodcasts() {
      patchState(store, { loading: true });
      const allPodcasts = await lastValueFrom(podcastService.getAll());
      patchState(store, { podcasts: allPodcasts, loading: false });
    },
  }));

Explanation:

The withProps function is used to inject dependencies like PodcastService directly into the store. This makes the service available across all methods without needing to repeatedly inject it.
This approach improves readability and reduces boilerplate by centralizing dependency injection.

2. Improved Dependency Injection

In the updated code, dependencies are grouped using withProps, which aligns with the NgRx documentation's recommendation for managing shared dependencies.

Documentation Reference:

"Dependencies required across multiple store features can be grouped using withProps."

Example from Docs:

withProps(() => ({
  booksService: inject(BooksService),
  logger: inject(Logger),
})),

Impact:

By grouping dependencies, we ensure that services like PodcastService are consistently injected and reused throughout the store.
This also simplifies testing, as dependencies can be mocked or replaced more easily.

3. Enhanced Method Definitions

The updated code refactors method definitions to leverage destructuring of the store and its properties. This results in cleaner and more concise code.

Original Code:

withMethods((store, podcastService = inject(PodcastService)) => ({
  async getAllPodcasts() {
    patchState(store, { loading: true });
    const allPodcasts = await lastValueFrom(podcastService.getAll());
    patchState(store, { podcasts: allPodcasts, loading: false });
  },
}));

Updated Code:

withMethods(({ podcastService, ...store }) => ({
  async getAllPodcasts() {
    patchState(store, { loading: true });
    const allPodcasts = await lastValueFrom(podcastService.getAll());
    patchState(store, { podcasts: allPodcasts, loading: false });
  },
}));

Explanation:

The updated syntax uses object destructuring to extract podcastService and the rest of the store (...store) directly within the method definition.
This eliminates the need to pass podcastService as a separate parameter, improving clarity and reducing redundancy.

4. Consistency with NgRx Documentation

The updated code aligns closely with the examples provided in the NgRx documentation, particularly in how withProps and withMethods are used together.

Documentation Example:

withMethods(({ booksService, logger, ...store }) => ({
  async loadBooks(): Promise {
    logger.debug('Loading books...');
    patchState(store, { isLoading: true });
    const books = await booksService.getAll();
    logger.debug('Books loaded successfully', books);
    patchState(store, { books, isLoading: false });
  },
})),

Impact:

Following the documented patterns ensures that the codebase adheres to best practices and remains maintainable.
It also makes it easier for developers familiar with NgRx to understand and contribute to the project.

Summary of Benefits

The updates to the NgRx Signal Store implementation bring several advantages:

Modularity: Dependencies are centralized using withProps, reducing duplication and improving organization.
Readability: Refactored method definitions and destructuring make the code easier to read and maintain.
Alignment with Best Practices: The updated code follows the latest NgRx documentation, ensuring compatibility and future-proofing.
Improved Developer Experience: Cleaner syntax and reduced boilerplate enhance the overall development workflow.

Conclusion

The introduction of withProps and the refinements to method definitions represent significant improvements in the NgRx Signal Store API. These changes not only simplify the code but also align it with modern Angular and NgRx best practices. As you continue to build and maintain your Angular applications, leveraging these updates will help you create more efficient and scalable state management solutions.

Happy coding! 🚀

Mastering State Management with NgRx Signal Store in Angular 🚀

JesúsB — Mon, 10 Feb 2025 10:18:12 +0000

In the ever-evolving landscape of Angular development, efficient state management is crucial for building scalable and maintainable applications. Enter NgRx Signal Store, a powerful solution that combines the simplicity of Angular's Signals API with the robustness of NgRx. Let's dive into how you can leverage NgRx Signal Store to streamline your state management in Angular applications.

What is NgRx Signal Store?

NgRx Signal Store is a state management library that integrates seamlessly with Angular's Signals API. It provides a structured way to manage application state, offering benefits such as:

Centralized state management
Reactive updates with Signals
Computed properties for derived state
Type-safe state modifications
Easy integration with Angular's dependency injection

Setting Up NgRx Signal Store

To get started with NgRx Signal Store, you first need to install it in your Angular project.

bun add @ngrx/signals@latest

Creating a Signal Store

Let's look at a real-world example of how to create a Signal Store for managing podcast data:

type PodcastStoreState = {
  podcasts: Podcast[];
  myPodcasts: Podcast[];
  loading: boolean;
  filter: { query: string; order: 'asc' | 'desc' };
};

const initialState: PodcastStoreState = {
  podcasts: [],
  myPodcasts: [],
  loading: false,
  filter: { query: '', order: 'asc' },
};

const STORE_STATE = new InjectionToken<PodcastStoreState>('PodcastStore', {
  factory: () => initialState,
});

export const PodcastStore = signalStore(
  { providedIn: 'root' },
  withState(() => inject(STORE_STATE)),
  withEntities<Podcast>(),
  withComputed(({ podcasts, myPodcasts, filter }) => ({
    subscribedPodcasts: computed(() =>
      podcasts().filter((podcast) =>
        myPodcasts().some((myPodcast) => myPodcast.id === podcast.id),
      ),
    ),
    sortByRating: computed(() => {
      const direction = filter().order === 'asc' ? 1 : -1;
      return podcasts().sort((a, b) => (a.rating - b.rating) * direction);
    }),
  })),
  withMethods((store, podcastService = inject(PodcastService)) => ({
    async getAllPodcasts() {
      patchState(store, { loading: true });
      const allPodcasts = await lastValueFrom(podcastService.getAll());
      patchState(store, { podcasts: allPodcasts, loading: false });
    },
    async getMyPodcasts() {
      patchState(store, { loading: true });
      const pods = await lastValueFrom(podcastService.getMyPodcasts());
      patchState(store, { myPodcasts: pods, loading: false });
    },
  })),
  withHooks({
    async onInit(store) {
      store.getAllPodcasts();
      store.getMyPodcasts();
    },
  }),
);

Key components of the store:

State Definition: We define the shape of our store state using TypeScript interfaces. Defined using an InjectionToken allowing us to inject values, services, or configurations.
Initial State: We set up the initial state of our store. Let's say "empty" in this case.
Store Creation: We can use the methods that signalStore provides to create our store, providing various configurations.

Computed Properties

One of the powerful features of NgRx Signal Store is the ability to create computed properties.

We can add computed signals to the store using the withComputed feature, which takes a factory function as its input.

withComputed(({ podcasts, myPodcasts, filter }) => ({
  subscribedPodcasts: computed(() =>
    podcasts().filter((podcast) =>
      myPodcasts().some((myPodcast) => myPodcast.id === podcast.id),
    ),
  ),
  sortByRating: computed(() => {
    const direction = filter().order === 'asc' ? 1 : -1;
    return podcasts().sort((a, b) => (a.rating - b.rating) * direction);
  }),
}));

This function runs within the injection context and returns a dictionary of computed signals.

It can leverage both previously defined state and existing computed signals accessible through the function's input argument.

These computed properties allow us to efficiently derive state without unnecessary recalculations.

State Modifications

NgRx Signal Store provides a clean way to modify state through methods:

withMethods((store, podcastService = inject(PodcastService)) => ({
  async getAllPodcasts() {
    patchState(store, { loading: true });
    const allPodcasts = await lastValueFrom(podcastService.getAll());
    patchState(store, { podcasts: allPodcasts, loading: false });
  },
  async getMyPodcasts() {
    patchState(store, { loading: true });
    const pods = await lastValueFrom(podcastService.getMyPodcasts());
    patchState(store, { myPodcasts: pods, loading: false });
  },
}));

These methods encapsulate the logic for updating our store, making it easy to manage complex state changes.
We can add methods to the store using the withMethods feature, which takes a factory function as its input and returns a dictionary of methods.
Like withComputed, the withMethods factory runs within the injection context, providing access to the store's instance, including previously defined state, computed signals, and methods.

Using the Store in Components

To use our NgRx Signal Store in a component, we can simply inject it and access its properties and methods:

@Component({
  selector: 'app-podcasts-container',
  standalone: true,
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    @let podcasts = store.podcasts();
    @defer (when podcasts) {
      <h2 class="text-2xl font-semibold text-center text-gray-800">
        All Podcasts
      </h2>
      <div class="grid gap-8 mt-8 sm:grid-cols-2 lg:grid-cols-3 xl:grid-cols-4">
        @for (podcast of podcasts; track podcast.id) {
          @defer (on viewport) {
            <app-podcast-item [podcast]="podcast" />
          } @placeholder {
            <app-skeleton />
          } @loading {
            <app-skeleton />
          }
        }
      </div>
    }
  `,
})
export class PodcastsContainerComponent {
  store = inject(PodcastStore);
}

This component injects our PodcastStore and uses its podcasts signal in the template, demonstrating how easy it is to consume state from our store.

Benefits of NgRx Signal Store

Reactivity: Changes to the store automatically update all subscribers, thanks to Signals.
Performance: Computed properties and fine-grained updates lead to optimal performance.
Type Safety: TypeScript integration provides excellent type checking and autocompletion.
Testability: The structure of Signal Stores makes unit testing straightforward.
Developer Experience: Simplified API compared to traditional NgRx, reducing boilerplate.

Conclusion

NgRx Signal Store represents a significant step forward in state management for Angular applications. By combining the power of NgRx with the simplicity of Signals, it offers a robust yet developer-friendly solution for managing application state.

As you build your next Angular application, consider how NgRx Signal Store can help you create more maintainable, performant, and scalable state management solutions. Happy coding! 🚀

Boosting Angular Performance: @defer, Lazy Loading, and Core Web Vitals

JesúsB — Wed, 05 Feb 2025 11:55:08 +0000

🔍 Understanding Core Web Vitals

Before we dive in, let's quickly recap what Core Web Vitals are:

Largest Contentful Paint (LCP): Measures loading performance. 🖼️
Interaction to Next Paint (INP): Measures overall responsiveness. ⚡ - INP replaced First Input Delay (FID) in March 2024.
Cumulative Layout Shift (CLS): Measures visual stability. 📏

Note: First Input Delay (FID) is no longer a Core Web Vital. It measured initial interactivity, aiming for values less than 100 milliseconds for a good user experience. INP now provides a more comprehensive measure of responsiveness throughout the user's entire session.

🧩 The Power of `@defer`

Angular's @defer block is a game-changer for performance optimization. It allows you to defer the loading of component trees until they're needed. Here's an example:

@Component({
  selector: 'app-home',
  template: `
    <h1>Welcome to Our Podcast App</h1>
    <app-featured-podcasts />
    @defer (on viewport) {
      <app-podcast-list [podcasts]="podcasts" />
    } @placeholder {
      <p>Scroll down to see more podcasts...</p>
    }
  `,
})
export class HomeComponent {
  podcasts = inject(PodcastStore).podcasts;
}

In this example, the app-podcast-list component will only be loaded when it enters the viewport, but it starts prefetching when the browser is idle.

On idle will trigger the deferred loading once the browser has reached an idle state. This is the default behavior with a defer block.

🎯 Impact on Core Web Vitals

Improves LCP: Deferring non-critical content allows faster loading of main content. Lazy loading reduces initial bundle size, speeding up load times.
Enhances INP: By deferring non-essential interactivity, the app remains responsive throughout the user's session. Prefetching during idle time ensures smoother interactions when content is needed.
Minimizes CLS: Using placeholders prevents layout shifts as deferred content loads.

🏋️ Lazy Loading: The Perfect Companion

Combine @defer with lazy loading for even better performance:

const routes: Routes = [
  {
    path: 'podcasts',
    loadComponent: () =>
      import('./podcasts/podcasts.component').then((m) => m.PodcastsComponent),
  },
];

This approach loads the entire PodcastsComponent only when the user navigates to the /podcasts route.

🎯 Core Web Vitals impact

Further improves LCP: Initial bundle size is reduced, leading to faster load times.
Boosts FID: Less JavaScript to parse on initial load means the app becomes interactive faster.

🔧 Practical Implementation Tips

Prioritize Above-the-fold Content

Use @defer for below-the-fold content to improve LCP.

@Component({
  selector: 'app-home',
  template: `
    <app-header />
    <app-featured-podcasts />
    @defer (on viewport; prefetch on idle) {
      <app-podcast-categories />
    } @placeholder {
      <div>...</div>
    }
  `,
})
export class HomeComponent {}

Smart Prefetching

For critical paths, use prefetch with @defer:

@let podcasts = store.podcasts();
@defer (on interaction; prefetch when podcasts) {
  <!-- content -->
} @placeholder {
  <div>...</div>
}

Multiple event triggers can be defined at once.

Lazy Load Feature Modules

Group related functionality into feature modules and lazy load them:

const routes: Routes = [
  {
    path: 'admin',
    loadChildren: () =>
      import('./admin/admin.module').then((m) => m.AdminModule),
  },
];

Use Standalone Components

They can be lazy-loaded individually, offering finer-grained control:

const routes: Routes = [
  {
    path: 'profile',
    loadComponent: () =>
      import('./profile.component').then((m) => m.ProfileComponent),
  },
];

🎭 Real-world Scenario: Podcast Streaming App

Let's look at how we might apply these techniques in a podcast streaming app:

@Component({
  selector: 'app-podcasts-container',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    @let podcasts = store.podcasts();
    @defer (when podcasts) {
      <h2 class="text-2xl capitalize lg:text-3xl">All Podcasts</h2>
      <div class="grid gap-8 mt-8">
        @for (podcast of podcasts; track podcast.id) {
          @defer (on viewport) {
            <app-podcast-item [podcast]="podcast" />
          } @placeholder {
            <app-skeleton />
          }
        }
      </div>
    }
    @defer (on interaction; prefetch when isLoggedIn()) {
      <app-add-to-favorites [podcast]="podcast" />
    } @placeholder {
      <div>...</div>
    }
    @defer (on timer(5s); prefetch on idle) {
      <app-related-podcasts [category]="podcast.category" />
    } @placeholder {
      <div>...</div>
    }
  `,
})
export class PodcastsContainerComponent {
  store = inject(PodcastStore);
  isLoggedIn = inject(AuthService).isLoggedIn();
}

This example:

Loads critical content immediately.
Defers episode list, loading when in viewport and prefetching during idle time.
Defers and prefetches "Add to Favorites" based on user login state.
Defers related podcasts, loading after 5 seconds but prefetching during idle time.

This approach significantly improves all Core Web Vitals:

LCP: Critical content loads first.
INP: Interactivity is improved by deferring non-essential components.
CLS: Placeholders prevent layout shifts as content loads.

📊 Measuring the Impact

Always measure the impact of your optimizations:

Use Chrome DevTools' Performance tab to analyze loading, scripting, and rendering times.
Leverage Lighthouse for a comprehensive performance audit, including Core Web Vitals scores.
Monitor real-user metrics using tools like Google Analytics or custom performance tracking.

🏁 Conclusion

By leveraging @defer blocks with placeholders, loading states, and prefetching, combined with lazy loading, you can significantly improve your Angular app's performance and Core Web Vitals scores. Remember, performance optimization is an ongoing process. Continuously measure, optimize, and iterate for the best results.

The key is to understand your user's journey and prioritize content accordingly. Use @defer and lazy loading strategically to create a fast, responsive, and smooth user experience.

Have you implemented @defer or lazy loading in your Angular projects? What improvements did you see? Share your experiences in the comments below! 💬

DON'T MISS: Your angular forms strongly typed based on your interface :rocket:

JesúsB — Wed, 05 Feb 2025 11:53:36 +0000

📌 Strongly Typed Forms in Angular Without Duplicating Interfaces

David Garcia ・ Feb 4

#angular #angularforms #typescript

Architecting Angular Applications: A Case Study in Scalable and Maintainable Design 🚀

JesúsB — Thu, 16 Jan 2025 14:42:42 +0000

In the ever-evolving landscape of web development, creating a scalable and maintainable Angular application is crucial for long-term success. 🏗️ Today, we'll dive into a case study of an architecture that promotes these qualities, examining its structure and benefits. We'll explore how this architecture was used to build a music streaming application (simplified for this example) with a growing library of podcasts and user features. 🎧

Who Is This Article For? 👨‍💻👩‍💻

This article is designed for intermediate to advanced Angular developers who are looking to refine their application architecture for better scalability and maintainability. If you're familiar with the basics of Angular components, services, and state management but want to dive deeper into best practices and architectural patterns, this is for you! 👍

The Folder Structure: A Foundation for Clarity 🗂️

A well-organized folder structure is the backbone of a maintainable application. Here’s a folder structure that has proven effective:

src/
  app/
    components/
    services/
    models/
    adapters/
    store/
    utils/
  environments/

Each folder serves a distinct purpose, contributing to a modular and scalable architecture.

Why This Structure? 🤔

Modularity: Each folder serves a specific purpose, making it easy to locate and manage different aspects of the application. 🧩
Scalability: As the application grows (e.g., adding new features like user playlists, music recommendations, etc.), new features can be added within their respective folders without cluttering the existing structure. 📈
Separation of Concerns: Clear separation between components, services, and data models promotes cleaner, more maintainable code. 🧹

Components: The Building Blocks 🧱

In this structure, the components folder is further organized by feature:

components / podcasts / podcasts - container.component.ts;
podcast - item / podcast - item.component.ts;
episodes / episodes - container.component.ts;
episode - item / episode - item.component.ts;

This setup provides several benefits:

Easy location of related components: As you scale, each feature or section of your app (e.g., podcasts, user authentication, playlists) remains self-contained. 📍
Scalability: New features (like a "Now Playing" bar or user profile page) can be added without affecting existing ones. ➕
Separation of concerns: Different parts of your app are kept distinct, reducing complexity. 🤯

Smart vs. Dumb Components 🧠

Within this structure, we follow the pattern of smart (container) and dumb (presentational) components. For example, podcast-container.component.ts would be a smart component that fetches podcast data from the store and passes it to the dumb component podcast-item.component.ts for display. This further enhances the separation of concerns and reusability.🔄

Services: The Data Management Layer 🗄️

The services folder contains all services responsible for data management and business logic. Services are centralized to promote reusability and consistency:

@Injectable({
  providedIn: 'root',
})
export class PodcastService {
  readonly #apiService = inject(ApiService);

  getAllPodcasts() {
    return toSignal(this.getAll());
  }

  getAll() {
    return this.apiService
      .get<Broadcast[]>(`${this.PATH}`)
      .pipe(map(PodcastAdapter));
  }
}

This centralized approach:

Promotes reusability across the application. For example, the PodcastService can be used by multiple components throughout the app. ♻️
Simplifies maintenance by centralizing data fetching logic. If the API endpoint changes, you only need to update it in one place. 🛠️
Provides a clear interface for components to interact with data. 🤝

Models: Defining the Shape of Data 📐

The models folder contains interfaces that define the shape of our data. This improves both type safety and code readability:

export interface Podcast {
  id: string;
  title: string;
  description: string;
  image: string;
  category: string;
  rating: number;
  website: string;
}

Benefits:

Enhanced type safety across the application, reducing runtime errors. 🔒
Clear structure for incoming and outgoing data. 📊
Easier refactoring and future-proofing. 🔮

Adapters: Bridging External and Internal Data Structures 🌉

The adapters folder transforms external API data into a format the application can easily consume:

export const PodcastAdapter = (pods: Broadcast[]): Podcast[] =>
  pods.map((pod) => ({
    id: pod.id,
    title: pod.title,
    description: pod.description,
    image: pod.image,
    category: pod.category,
    rating: pod.average_rating,
    website: pod.website,
    subscribers: pod.subscribers,
    language: pod.language,
  }));

By using adapters, you decouple your application from external data structures, making it easier to handle API changes and ensuring consistent data transformations across your app. This is also beneficial for testing, as you can easily mock API responses by providing data that is already in the format expected by your application. 🧪

Store: Managing Application State with NgRx SignalStore 🚦

For state management, we’re using NgRx SignalStore, which combines the power of NgRx with the simplicity of Angular's Signals API. We chose SignalStore for this application because it provides a streamlined way to manage state and reactivity while leveraging the familiar concepts of NgRx.

Why NgRx SignalStore? 🤔

Centralized State: All state related to podcasts (and potentially other features like user authentication and playlists) is managed in one place. This makes it easier to track changes and debug issues. 🎯
Computed Properties: Computed signals help with derived state, like filtered or sorted podcasts, improving performance by only recalculating when dependencies change. ⚡️
Methods for State Changes: Actions that modify state are defined as methods, simplifying logic and improving predictability. This makes it easier to reason about how state changes over time. 🧠
Improved Performance: SignalStore can offer performance advantages over traditional NgRx stores, especially in applications with frequent state updates. 🚀

export const PodcastStore = signalStore(
  { providedIn: 'root' },
  withState<PodcastStoreState>(...),
  withComputed(...),
  withMethods(...),
  withHooks(...)
);

This setup allows for efficient reactivity, centralized management, and predictability in state changes, making it easier to debug and test. 🐛

Note: While SignalStore offers many benefits, it's important to be aware of potential drawbacks. For example, debugging complex state changes can be challenging, and migrating from a traditional NgRx store can require significant refactoring. ⚠️

Benefits of This Architecture ✨

Scalability: New features, like user profiles or personalized recommendations, can be added without disrupting existing code. 📈
Maintainability: Clear separation of concerns makes the code easier to understand, update, and debug. 🛠️
Reusability: Services and components are modular, making them reusable across the app. ♻️
Testability: Modular structure facilitates easier unit testing. For instance, you can easily isolate components and mock dependencies like services and the NgRx SignalStore. 🧪
Collaboration: Teams can work on different parts of the app (e.g., a team focused on podcasts and another on user accounts) with minimal conflict. 🤝

Conclusion 🎉

This architecture provides a solid foundation for building scalable and maintainable Angular applications. By separating concerns, promoting modularity, and following consistent patterns, you can create a codebase that evolves with your needs.

Remember, the best architecture serves your specific project requirements. Be ready to adapt and evolve your structure as your application grows and new insights emerge.

What has been your experience with Angular application architecture? Have you used similar patterns in your projects? Let’s discuss in the comments! 👇

Streamlining Data Flow in Angular: The Power of the Adapter Pattern 🔄

JesúsB — Mon, 13 Jan 2025 13:57:07 +0000

In modern web development, especially with Angular, we often grapple with data from various sources that don't align perfectly with our application's models. Enter the Adapter pattern - a game-changer for creating robust and maintainable Angular applications. Let's dive in!

🧩 What is the Adapter Pattern?
The Adapter pattern is a structural design pattern that allows objects with incompatible interfaces to collaborate. In Angular, we use it to transform external API data into a format our application can easily consume.

🌟 Why Use the Adapter Pattern?

Decoupling: Separates data fetching from data shaping.
Flexibility: Easily adapt to API changes without affecting the entire app.
Consistency: Ensures uniform data structure throughout your application.
Testability: Simplifies testing data transformations in isolation.

💻 Real-World Example
Let's look at a PodcastAdapter from a podcast app:

import { Broadcast, Podcast } from '@models';

export const PodcastAdapter = (pods: Broadcast[]): Podcast[] =>
  pods.map((pod) => ({
    id: pod.id,
    title: pod.title,
    description: pod.description,
    image: pod.image,
    category: pod.category,
    rating: pod.average_rating,
    website: pod.website,
    subscribers: pod.subscribers,
    language: pod.language,
  }));

🔍 Breaking It Down

Input: Array of Broadcast objects (raw API data)
Output: Array of Podcast objects (our app's model)
Transformation: Mapping each Broadcast to a Podcast, renaming properties as needed

@Injectable({
  providedIn: 'root',
})
export class PodcastService {
  private readonly apiService = inject(ApiService);

  getAllPodcasts() {
    return toSignal(this.getAll());
  }

  getAll() {
    return this.apiService
      .get<Broadcast[]>(`${this.PATH}`)
      .pipe(map(PodcastAdapter));
  }
}

🛠️ Where to Use the Adapter
Typically in services, right after fetching API data:

🎯 Benefits in Action

API Resilience: Only update the adapter if API changes, not every component.
Data Consistency: Uniform podcast data structure across the app.
Type Safety: Leverage TypeScript for better error catching and IDE support.
Isolated Testing: Easily unit test the adapter function.

🚀 Best Practices

Keep It Simple: Focus solely on data transformation.
Embrace TypeScript: Define clear interfaces for input and output.
Centralize Adapters: Maintain a dedicated adapters folder.
Consider Inverse Adapters: For sending data back to the API.

💡 Pro Tip: Use adapters with Angular's new toSignal() function for seamless integration with the signals API!

🏁 Conclusion
The Adapter pattern is a powerful tool for managing the complexities of data transformation in Angular. It creates a clear boundary between external data and internal structures, enhancing maintainability, flexibility, and robustness.

As you build your next Angular masterpiece, consider how the Adapter pattern can elevate your data management game!

🤔 Have you used the Adapter pattern in your Angular projects? What challenges did it help you overcome? Let's discuss in the comments!!.

Mastering the Container-Presenter Pattern in Angular: A Deep Dive

JesúsB — Thu, 19 Dec 2024 15:03:28 +0000

In the world of Angular development, structuring your components effectively can make a significant difference in the maintainability and scalability of your application. Today, let's explore a powerful pattern that has become a cornerstone in many Angular projects: the Container-Presenter pattern.

🧩 What is the Container-Presenter Pattern?
The Container-Presenter pattern, also known as Smart and Dumb Components or Stateful and Stateless Components, is a design pattern that promotes a clear separation of concerns in your Angular components. Let's break it down:

Container (Smart) Components: These components are responsible for how things work. They manage state, fetch data, and contain business logic.
Presenter (Dumb) Components: These components are responsible for how things look. They receive data via inputs and emit events via outputs, focusing solely on the presentation.

🌟 Why Use This Pattern?

Improved Testability: Presenter components are easier to test as they don't depend on services or state management.
Enhanced Reusability: Presenter components can be reused across different parts of your application.
Better Separation of Concerns: Each component has a clear, single responsibility.
Easier Maintenance: Changes to business logic or data fetching don't affect the presentation layer, and vice versa.

💻 Real-World Example
Let's look at a real-world example from a podcast application I've been working on:

Container Component:

@Component({
  selector: 'app-podcasts-container',
  standalone: true,
  imports: [PodcastItemComponent, SkeletonComponent],
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    @let podcasts = store.podcasts();
    @defer (when podcasts) {
      <h2
        class="text-2xl font-semibold text-center text-gray-800 capitalize lg:text-3xl dark:text-white"
      >
        All Podcasts
      </h2>
      <div class="grid gap-8 mt-8 sm:grid-cols-2 lg:grid-cols-3 xl:grid-cols-4">
        @for (podcast of podcasts; track podcast.id) {
          @defer (on viewport) {
            <app-podcast-item [podcast]="podcast" />
          } @placeholder {
            <app-skeleton [type]="'CARD'" />
          } @loading {
            <app-skeleton [type]="'CARD'" />
          }
        }
      </div>
    }
  `,
})
export class PodcastsContainerComponent {
  store = inject(PodcastStore);
}

This container component:

Injects the PodcastStore to access the application state
Uses the @defer directive for lazy loading and better performance
Iterates over the podcasts and renders PodcastItemComponent for each

Presenter Component:

@Component({
  selector: 'app-podcast-item',
  standalone: true,
  imports: [NgOptimizedImage],
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    @if (podcast(); as podcast) {
      <div
        class="overflow-hidden bg-white rounded-lg shadow-lg dark:bg-gray-800"
      >
        <div class="px-4 py-2">
          <h1 class="text-xl font-bold text-gray-800 uppercase dark:text-white">
            {{ podcast.title }}
          </h1>
          <p class="mt-1 text-sm text-gray-600 dark:text-gray-400">
            {{ podcast.description }}
          </p>
        </div>
        <img
          class="object-cover w-full h-48 mt-2"
          [src]="podcast.image"
          [alt]="podcast.title"
        />
        <div class="flex items-center justify-between px-4 py-2 bg-gray-900">
          <h1 class="text-lg font-bold text-white">{{ podcast.rating }}</h1>
          <button
            class="px-2 py-1 text-xs font-semibold text-gray-900 uppercase transition-colors duration-300 transform bg-white rounded hover:bg-gray-200 focus:bg-gray-400 focus:outline-none"
          >
            Subscribe
          </button>
        </div>
      </div>
    }
  `,
})
export class PodcastItemComponent {
  podcast = input.required<Podcast>();
}

This presenter component:

Receives a podcast input
Focuses solely on rendering the podcast information
Has no knowledge of where the data comes from or how it's managed

🎯 Benefits in Action

Reusability: The PodcastItemComponent can be easily reused in other parts of the application, such as a "Featured Podcasts" section or a search results page.
Testability: Testing the PodcastItemComponent is straightforward as we can simply pass in mock podcast data and assert on the rendered output.
Separation of Concerns: The PodcastsContainerComponent handles data fetching and state management, while PodcastItemComponent focuses purely on presentation.
Performance: By using ChangeDetectionStrategy.OnPush, we optimize change detection for both components.

🚀 Conclusion
The Container-Presenter pattern is a powerful tool in an Angular developer's arsenal. It promotes clean, maintainable, and scalable code by clearly separating concerns between data management and presentation.

As you structure your Angular applications, consider how this pattern can benefit your project. It may require a bit more initial setup, but the long-term benefits in terms of maintainability, testability, and scalability are well worth it.

💬 Have you used the Container-Presenter pattern in your Angular projects? What benefits or challenges have you encountered? Let's discuss in the comments!

Modernizing Angular: Embracing Fetch API for Better Performance and Security

JesúsB — Tue, 17 Dec 2024 11:52:57 +0000

As Angular evolves, it brings exciting changes that streamline our development process and enhance our applications. One such change is the introduction of app.config.ts, where we now define providers for bootstrapping our main component. Today, let's highlight a simple yet powerful feature: switching Angular's HttpClient to use the Fetch API.

🔄 The Shift from XMLHttpRequest to Fetch
Traditionally, Angular's HttpClient relied on XMLHttpRequest (XHR) for handling HTTP requests. While XHR has served us well, the web platform has evolved, offering more modern alternatives.

Enter the Fetch API - a contemporary approach to making HTTP requests. With Angular's new configuration options, we can now easily switch HttpClient to use Fetch instead of XHR.

🌟 Why Consider the Switch?

Performance Boost: Fetch is designed with modern web applications in mind, offering potential performance improvements, especially for complex applications.
Enhanced Security: Fetch comes with better support for modern security features like CORS and Content Security Policy, helping to fortify our applications against common vulnerabilities.
Simplified Promise-based API: Fetch provides a cleaner, more intuitive API based on Promises, aligning well with modern JavaScript practices.
Future-Proofing: As the web evolves, Fetch is more likely to receive updates and improvements compared to the older XHR.

🛠️ How to Make the Switch
Implementing this change is surprisingly simple. In your app.config.ts, use the withFetch() option when providing HttpClient:

import { provideHttpClient, withFetch } from '@angular/common/http';
import { ApplicationConfig } from '@angular/core';

export const appConfig: ApplicationConfig = {
  providers: [
    // ... other providers
    provideHttpClient(withFetch()),
  ],
};

This small change can have a significant impact on your application's performance and security posture.

⚖️ Considerations
While Fetch offers numerous advantages, it's worth noting that it has some limitations. For instance, it doesn't support upload progress events, which might be crucial for certain applications. Always evaluate your specific needs before making the switch.

🎯 Conclusion
As Angular continues to embrace modern web standards, features like withFetch() offer us simple ways to keep our applications cutting-edge. By adopting these new capabilities, we not only potentially improve performance and security but also future-proof our applications.

💬 Have you tried switching to Fetch in your Angular applications? I'd love to hear about your experiences! Share your thoughts in the comments - did you notice any performance improvements? Any challenges you faced? Let's discuss and learn from each other's experiences!

New in Angular: Bridging RxJS and Signals with toSignal!

JesúsB — Tue, 17 Dec 2024 11:33:49 +0000

Angular developers, are you ready to simplify your reactive programming? Let me introduce you to toSignal, a game-changing feature that seamlessly connects RxJS Observables with Angular's new Signals API.

🔗 What is toSignal?
It's a function that converts an Observable into a Signal, giving you the best of both worlds - the power of RxJS and the simplicity of Signals.

💡 Key benefits:

Streamlined code: No more async pipe in templates
Automatic subscription management
Use anywhere in your app, not just in templates
Improved performance and change detection

Here's a quick example from a recent project:

export class EpisodesService {
  readonly path = '/episodes';
  readonly #api = inject(ApiService);

  getAllEpisodes(): Signal<Episode[]> {
    return toSignal(
      this.#api.get<Chapter[]>(this.path).pipe(map(EpisodeAdapter)),
      { initialValue: [] },
    );
  }
}

And here's how you can use it in a component:

@Component({
  selector: 'app-episodes-container',
  template: `
    @for (episode of episodes(); track episode.id) {
      <app-episodes-item [episode]="episode" />
    }
  `,
})
export class EpisodesContainerComponent {
  episodes = inject(EpisodesService).getAllEpisodes();
}

We're fetching data from an API, transforming it with EpisodeAdapter, and then wrapping the resulting Observable with toSignal(). Now, any component using this service can easily consume the episode data as a Signal!

In the template, we can directly use episodes() to access the latest value, just like any other Signal!
⚠️ Important Note: The RxJS Interop package (@angular/core/rxjs-interop) is currently available for developer preview. While it's ready for experimentation, be aware that it might undergo changes before reaching a stable release.

🚀 Ready to level up your Angular skills? Start experimenting with toSignal in your projects today!!

What do you think? Want to dive deeper into Signals and RxJS integration? Let me know in the comments!.

Modern Testing Practices in Angular: From Unit to Integration Testing

JesúsB — Mon, 16 Dec 2024 11:01:03 +0000

In the dynamic world of web development, ensuring the reliability and maintainability of your applications is paramount. 🌐 Angular, one of the leading frontend frameworks, has been at the forefront of this endeavor, evolving its testing strategies to keep pace with industry best practices.

In this article, we'll explore the insights shared by Rainer Hanekamp, a trainer and consultant at Angular Architects, who advocates for a significant shift from traditional unit testing to more comprehensive integration testing in Angular applications. 🚀

All insights in this article are based on Rainer Hanekamp's video, which provides a deep dive into modern testing practices in Angular. 🎥

Introduction to Modern Testing in Angular

Angular has long been a favorite among developers, not just for its robust features but also for its seamless integration with testing tools. 🛠️

The Angular CLI, for instance, automatically generates test files for each new component or service, promoting a unit-test-per-file approach. However, as applications grow in complexity, this method can become cumbersome and less effective. ⚡

Rainer Hanekamp highlights that modern testing practices are moving towards more holistic tests that cover multiple files, aligning with industry trends and recommendations from the Angular team itself. 🌟

Defining Testing Terms and Types

Before diving deeper, it's crucial to establish a common understanding of testing terminology, as definitions can vary across different teams and projects. 📖

Unit Tests: Focus on individual classes or components in isolation. They interact directly with the TypeScript class methods and properties, mocking all dependencies to ensure that only the unit under test is evaluated. ✅
Component Tests: Similar to unit tests but involve interacting with the component's template via the DOM. This means simulating user interactions like clicks and inputs and asserting changes in the rendered output. 🖱️
Integration Tests: Broader in scope, these tests cover multiple components and services working together. They aim to verify that different parts of the application interact correctly, without mocking as many dependencies as unit tests. 🤝
End-to-End (E2E) Tests: Simulate real user scenarios by testing the entire application flow from start to finish. They operate outside the Angular context, interacting with the application as a user would, regardless of the frontend framework used. 🔄

Traditional Unit Testing in Angular

The traditional unit testing approach would involve:

Isolate the Component: Focus solely on component, ignoring its template and child components.
Mock Dependencies: Replace services with mocks to ensure the test only evaluates the component's logic. 🧩
Assert Internal State: Verify that methods are called with expected arguments and that internal properties behave as intended. 📋

While this approach ensures that the component's logic works in isolation, it doesn't provide confidence that the component interacts correctly with other parts of the application.

Introduction to Integration Testing

Integration testing addresses the limitations of unit testing by evaluating how different parts of the application work together. In the context of Angular: 🕸️

Interaction via the DOM: Tests simulate user interactions such as clicking buttons and filling forms, then assert changes in the DOM. 🖱️
Real Dependencies: Instead of mocking all dependencies, integration tests use real services and components where feasible, mocking only external systems like HTTP requests. 🌐
Comprehensive Coverage: A single integration test can cover multiple components and services, providing a broader overview of the application's functionality. 🌟

Comparing Unit Tests and Integration Tests

Unit Tests

Pros:
✅ Speed: Unit tests are typically faster to execute since they focus on small, isolated units.
✅ Precision: They can pinpoint specific issues within a component or service.
✅ Edge Case Handling: Ideal for testing complex logic and handling edge cases.

Cons:
⚠️ Tight Coupling: Unit tests are closely tied to implementation details, making refactoring challenging.
⚠️ High Maintenance: Changes in the codebase often require updates to numerous unit tests.
⚠️ Limited Scope: They don't provide insights into how different parts of the application interact.

Integration Tests

Pros:
✅ Realistic Scenarios: By interacting with the DOM and using real dependencies, integration tests better simulate real user behavior.
✅ Refactoring-Friendly: Less dependent on specific implementations, allowing for easier codebase refactoring.
✅ Broader Coverage: A single test can cover multiple components and services, enhancing overall coverage.

Cons:
⚠️ Slower Execution: Integration tests can be slower than unit tests due to their broader scope.
⚠️ Complex Setup: Requires a more sophisticated testing environment and handling of dependencies.
⚠️ Potential for Flakiness: More components interacting can introduce variability, though this is mitigated with proper tooling.

Modern Testing Models and Recommendations

The Testing Trophy Model 🏆

Moving away from the traditional Testing Pyramid, the Testing Trophy model prioritizes:

Static Tests: TypeScript type checks and linting. 🔍
Integration Tests: The bulk of testing efforts focus here. 🤝
End-to-End Tests: Fewer but essential tests covering critical user flows. 🔄
Unit Tests: Reserved for complex logic and edge cases where necessary. ✅

Insights from the Angular Team on Testing Practices

Jeremy Elborn, the tech lead of the Angular project, reinforces the importance of realistic and resilient tests:

"You want your tests to be as representative of real life as is practical... Use the real implementation when it makes sense... Only use mocks as really a last resort when you have no other options." 🎤

This perspective underscores the shift towards integration testing, advocating for tests that mirror actual user interactions and application behavior rather than focusing solely on isolated units. 🌍

Action Points for Developers:

Evaluate Current Testing Tools: Assess whether your existing testing setup aligns with modern practices. 🛠️
Plan for Transition: If considering Playwright or other integration-focused tools, develop a roadmap for adoption. 🗺️
Invest in Training: Equip your team with the skills needed to utilize new testing frameworks effectively. 📚
Revise Testing Guidelines: Update your internal documentation to reflect current best practices. 📝

Have thoughts or experiences with modern Angular testing? Share them in the comments below!

Modernizing Angular: What's New in Angular 19

JesúsB — Tue, 26 Nov 2024 14:00:00 +0000

Angular 19 has officially arrived, and it's packed with a range of features aimed at improving developer experience, performance, and adaptability.

In this article, I'll walk you through the key highlights and what makes Angular 19 a pivotal step forward for modern web development.

1. Incremental Hydration: A Game Changer for SSR

The introduction of incremental hydration in Angular 19 takes Server-Side Rendering (SSR) to new heights. Unlike the traditional full hydration approach, incremental hydration allows the server-rendered components to hydrate only when they enter the viewport or become interactive.

This results in faster load times and a better user experience. This feature is currently in developer preview, but it’s showing great promise for optimizing the initial load and improving Lighthouse scores.

To achieve this, Angular collaborated with Chrome Aurora to bring a more seamless SSR experience that is adaptable to real-world usage, focusing on lazy hydration. Developers can now use directives like @defer to control exactly when a component should be hydrated, making the process highly efficient.

import { provideClientHydration, withIncrementalHydration } from '@angular/platform-browser';

bootstrapApplication(AppComponent, {
  providers: [
    provideClientHydration(withIncrementalHydration())
  ]
});

@defer (hydrate on viewport) {
  <shopping-cart></shopping-cart>
}

2. Event Replay: Ensuring Smooth User Interactions

A common problem in server-side rendered apps is the delay between a user interaction and the JavaScript responsible for handling that interaction being loaded.

Event replay, now enabled by default in Angular 19, captures user events during the initial load and replays them when the necessary JavaScript becomes available. This ensures a smooth user experience, even if the app is still in the process of hydrating.

The event dispatch is powered by the same library used by Google Search (Wiz) and has been tested by billions of users.

To enable event replay, Angular uses the following setup in the hydration provider:

bootstrapApplication(App, {
  providers: [
    provideClientHydration(withEventReplay())
  ]
});

This ensures that any user interactions that occur before the JavaScript is fully loaded are not lost, providing a seamless experience.

3. Route-Level Render Mode: Fine-Grained Control Over Rendering

Angular 19 introduces route-level render mode, which allows developers to specify how individual routes in an application should be rendered—either on the server, client, or prerendered during the build process.

This provides fine-grained control over rendering strategy, allowing developers to optimize for performance and SEO based on the specific needs of each route.

Example: A login route can be server-side rendered for faster initial load times, while a dashboard route can be client-side rendered to enhance interactivity. This flexibility helps ensure that each part of the application is optimized for its intended use case.

export const serverRouteConfig: ServerRoute[] = [
  { path: '/login', renderMode: RenderMode.Server },
  { path: '/dashboard', renderMode: RenderMode.Client },
  { path: '/**', renderMode: RenderMode.Prerender },
];

Angular also provides an easy way to resolve route parameters during prerendering, allowing for highly customizable prerendered pages:

export const routeConfig: ServerRoute = [{
  path: '/product/:id',
  mode: 'prerender',
  async getPrerenderPaths() {
    const dataService = inject(ProductService);
    const ids = await dataService.getIds();
    return ids.map(id => ({ id }));
  },
}];

This new interface, ServerRoute, gives developers greater control over how content is delivered, improving both user experience and SEO.

4. Hot Module Replacement (HMR) Just Got Instant

Angular 19 introduces instant HMR, allowing styles and templates to be updated without reloading the entire app. This means that developers can see the effect of their changes immediately, making the development cycle much smoother and faster. Hot module replacement for styles is enabled by default in v19! To try HMR for templates use:

NG_HMR_TEMPLATES=1 ng serve

To disable this feature specify "hmr": false as a development server option, or alternatively use:

ng serve --no-hmr

5. Zoneless Support: Continued Evolution

Six months ago, Angular introduced experimental zoneless support. Since then, Angular has been iterating over the APIs and enhancing them—adding support for server-side rendering and improving the testing experience.

Angular partnered with the Google Fonts team to make their application zoneless and evaluate the developer experience. The results exceeded expectations, but there are still a few more polishing touches before moving this API to developer preview.

Angular 19 continues to push towards a future where zoneless operation becomes the default, significantly simplifying change detection and making applications leaner.

To experiment with zoneless, use the following setup:

bootstrapApplication(App, {
  providers: [
    provideExperimentalZonelessChangeDetection()
  ]
});

6. Linked Signals: Reactive State with Contextual Awareness

One of the coolest new additions is linked signals. With this feature, signals that are tied together maintain their relationships even when data updates. This is particularly useful for scenarios where multiple data points need to stay in sync dynamically. For instance, maintaining the state of a dropdown or a selection that is derived from another reactive source is now more straightforward and requires less boilerplate.

const options = signal(['Apple', 'Banana', 'Cherry']);
const selectedOption = linkedSignal(() => options()[0]);

// Initial value
console.log(selectedOption()); // Output: 'Apple'

// Update the selected option manually
selectedOption.set('Banana');
console.log(selectedOption()); // Output: 'Banana'

// Update the options array, and the linked signal will update accordingly
options.set(['Kiwi', 'Pineapple']);
console.log(selectedOption()); // Output: 'Kiwi'

The linkedSignal API provides a simple way to express dependencies between stateful elements without resorting to effects. The new API has two forms: a simplified version (shown here) and an advanced version that gives developers access to previous values of both the linked and source signals.

7. Angular Material Upgrades

Angular Material also got a significant upgrade in Angular 19. There's now a new, more customizable theming API, allowing developers to easily override styles and tweak the look and feel of Angular Material components without diving into deeply nested CSS. Each component's documentation also includes a Styling tab for easier reference on how to make these changes.

The much-anticipated Drag and Drop component has finally been added natively to Angular Material, allowing developers to implement sophisticated drag-and-drop interactions without relying on third-party libraries.

@use '@angular/material' as mat;

@include mat.core();
$my-theme: mat.define-light-theme((
  color: (
    primary: mat.define-palette(mat.$indigo-palette),
    accent: mat.define-palette(mat.$pink-palette, A200, A100, A400),
  ),
));

@include mat.all-component-themes($my-theme);

To customize individual components:

@include mat.sidenav-overrides(
  (
    'content-background-color': purple,
    'container-divider-color': orange,
  )
);

8. Migration Scripts for Signals

Migrating your app to the new signals-based reactivity model is now simpler thanks to the built-in migration scripts. These scripts help transition your existing inputs, outputs, and queries to use signals instead of the older Angular decorators, ensuring your app stays modern with minimal effort.

ng generate @angular/core:signal-input-migration

9. Enhanced Content Security Policy

Security is another key focus of this release. Angular 19 introduces support for auto CSP (Content Security Policy), which automatically adds a secure CSP configuration to your application to prevent XSS attacks and other vulnerabilities by default. This is a significant step towards better security practices with less manual configuration.

{
  "security": {
    "autoCsp": true
  }
}

10. The Future of Testing in Angular

Lastly, a major note on testing—Karma is being deprecated in favor of more modern tools like Jest and Web Test Runner. By mid-2025, Karma will no longer be supported, which gives developers ample time to migrate to a more reliable testing setup that integrates smoothly with the rest of the modern Angular ecosystem.

Wrapping Up

Angular 19 isn't just an update; it's a forward-thinking version that optimizes for both developer and user experience. With features like incremental hydration, event replay, route-level render modes, instant HMR, the move towards zoneless, and a plethora of productivity enhancements, this version brings Angular closer to its ideal—a modern, high-performance, developer-friendly framework.

If you're looking to migrate or start a new project, Angular 19 provides a solid foundation that supports cutting-edge features and evolving best practices. Let me know what features you're most excited about, or if you have any questions about adopting Angular 19 in your projects!

PIT, a mutation testing system for Java.

JesúsB — Tue, 15 Feb 2022 14:22:01 +0000

Mutation test introduces a way to find faults in our software components, verifying that our tests are able to detect unexpected behaviour. If they are able to find out the bugs caused by the mutations, we can affirm that our tests have good quality. However if defective tests are present, we should bear in mind that maybe a refactor of our tests will be needed to ensure good quality software.

PIT, is a mutation testing tool for JAVA, which is applicable in real world projects. PIT, is fast, robust and well integrated with other frameworks or tools, as it can be used vía Maven, Ant or terminal.

Thanks to this mutation tool, we will be able to apply a huge quantity of mutation of our code.

Is it not code coverage enough?.

TL;DR: No.

Nowadays it is well known by everybody the fact that software testing aims to check the expected behaviour of the software, making us to be able to detect bugs. One of the most important metrics in the industry of software development is code coverage.

But, is this a proper approach?. Should we care about something else? Why is not that enough?.

We can answer all theses questions with only one answer: because although our test is passing and we assume that our program works properly, having our lines covered does not mean that our pieces are well tested.

That's why mutation testing can be our friend - this technique will introduce defects vía small code modifications, and thanks to that and if our tests are consistent enough (so tests will fails if mutants are present), we can increase how well our software is tested.

👉 Code Coverage is a measurement of the percentage of code lines executed during the test suite.

Mutation testing.

Before jumping to the practical example, let's review the basic concepts of mutation testing.

Mutant operators: The ones who transform the syntax of the program, for instance, the expression a + b will be changed to a - b or a operator like < can be changed to >.
Mutants: Used to measure how good our tests are by observing and comparing the runtime behaviour of the non-mutated and mutated programs.
Mutations: We can find two types of mutations:
- Killed: Implies that there is at least one failing test as result of the mutation ✅.
- Survived: It means that zero tests detected the mutation and it must be improved ❌

Mutation testing example.

Today we're presenting a simple example of how can we apply PIT in a project, in this case, we are going to use a PoC that was developed some time ago. Tests weren't perfect and coverage was not the best, and that's why it can be a good example of how we can improve our project testing quality by relying on this framework.

As we have spotted before, PIT, is available for Maven, so getting started is as easy as adding the plugin to our pom.xml , inside the <build> tag.

<plugin>
    <groupId>org.pitest</groupId>
    <artifactId>pitest-maven</artifactId>
    <version>1.6.4</version>
    <dependencies>
        <dependency>
            <groupId>org.pitest</groupId>
            <artifactId>pitest-junit5-plugin</artifactId>
            <version>0.14</version>
        </dependency>
    </dependencies>
</plugin>

Now, we are able to run our test using the following instruction mvn --fail-at-end clean test pitest:mutationCoverage pitest:report-aggregate-module and a report will be generated, where we will be able to inspect the mutants, the killed and the survived.

This report will be available in the target folder, under the pit-report a index.html will be present:

Now we can open it in our browser and investigate the possible issues present in our codebase according to PIT.

As we can see, mutation coverage reports a 24% of mutation coverage, 27% of line coverage (based on our unit test coverage report). These is the global report for our project, which for simplicity we have configured PIT to exclude configuration classes, domain entities and repositories, leaving our services as the key for the success of the testing sources.

To be more concise and to exemplify how can we deal with PIT, we are going to focus on the com.bnd.io.discounts.service.impl package, and the CouponServiceImpl.java class.

Report for service package. ☝️

As we can see in this first report, the mutation coverage for the class of interest is 0%. But which are the mutants we have to solve?. We can have more details if we navigate to the class, and check what PIT points out.

CouponServiceImpl.java class ☝️

Mutations KILLED & SURVIVED ☝️

Wow, there's a lot of information here... let's start step by step. So in our service class we have some methods, this won't be extrange for anyone, repository calls, business logics, etc. And then after we executed our mutation test platform, it reports that we have some pitfalls, some methods are not even tested and the mutants, have survived.

Also a list of the active mutations is present, so we can know what is being applied in our test suite.

Killing the mutants...

Having concerned the above points, now, it's time to kill the mutants. So, let's go for it! 🚀

To be begin with we are going to focus on the mutations annotated as SURVIVED, we will deal with the NO_COVERAGE tests later. So solve the problem with the findAll we need to change our unit test CouponServiceImpl::findAll method, or add a new one:

@Test
void testFindAllShouldNotReturnNull() {
        final Coupon coupon = easyRandom.nextObject(Coupon.class);
    when(this.couponRepository.findAll(any(Pageable.class))).thenReturn(new PageImpl<>(List.of(coupon)));
        final Page<Coupon>result = couponServiceImpl.findAll(Pageable.unpaged());
        assertNotNull(result);
}

After running PIT, we added the previous test to kill that survived mutant. First mutant killed! 🤘

Let's add some more tests to have everything in place, for these first three tests, which mutants survived at the beginning:

We added these two test cases to achieve the current result:

@Test
void testFindOneShouldNotReturnEmpty() {
    final Coupon coupon = easyRandom.nextObject(Coupon.class);
    when(this.couponRepository.findById(any())).thenReturn(Optional.of(coupon));
        final Optional<Coupon>result = couponServiceImpl.findOne(1L);
    assertTrue(result.isPresent());
}

@Test
void testDelete() {
    couponServiceImpl.delete(1L);
        final Optional<Coupon>optionalCoupon = this.couponServiceImpl.findOne(1L);
    assertTrue(optionalCoupon.isEmpty());
    verify(couponRepository).deleteById(anyLong());
}

We still have to deal with some tests, as you can see, because we don't have even coverage for them, let's go for that!.

He have to bear in mind that we don't want to have any mutant!. Moreover it's important to focus on our tests verifications, this way, PIT mutants won't be able to survive, if the framework uses mutants of type removed call to → survived.

So finally, our test cases will remain as follow in order to kill all mutants present at the beginning.

@ExtendWith(SpringExtension.class)
class CouponServiceImplTest {

    public static final String COUPON_CODE = "CODE";
    @Mock
    private CouponRepository couponRepository;

    @InjectMocks
    private CouponServiceImpl couponServiceImpl;

    private EasyRandom easyRandom;

    @BeforeEach
    public void setup() {
        easyRandom = new EasyRandom();
        final Coupon coupon = easyRandom.nextObject(Coupon.class);
        when(this.couponRepository.findByCouponCodeAndActiveIsTrue(COUPON_CODE))
                .thenReturn(Optional.of(coupon));
        when(this.couponRepository.findAllByDiscountType_DiscountTypeCodeEqualsIgnoreCaseAndActiveIsTrue(COUPON_CODE))
                .thenReturn(List.of(coupon));
        when(this.couponRepository.findByCouponCode(COUPON_CODE))
                .thenReturn(Optional.of(coupon));
    }

    @AfterEach
    void tearDown() {
        verifyNoMoreInteractions(couponRepository);
    }

    @Test
    void testFindAll() {
        final Page<Coupon> result = couponServiceImpl.findAll(Pageable.unpaged());
        assertNull(result);
        verify(couponRepository).findAll(any(Pageable.class));
    }

    @Test
    void testFindAllShouldNotReturnNull() {
        final Coupon coupon = easyRandom.nextObject(Coupon.class);
        when(this.couponRepository.findAll(any(Pageable.class))).thenReturn(new PageImpl<>(List.of(coupon)));
        final Page<Coupon> result = couponServiceImpl.findAll(Pageable.unpaged());
        assertNotNull(result);
        verify(couponRepository).findAll(any(Pageable.class));
    }

    @Test
    void testFindOne() {
        final Optional<Coupon> result = couponServiceImpl.findOne(1L);
        assertEquals(Optional.empty(), result);
        verify(this.couponRepository).findById(anyLong());
    }

    @Test
    void testFindOneShouldNotReturnEmpty() {
        final Coupon coupon = easyRandom.nextObject(Coupon.class);
        when(this.couponRepository.findById(any())).thenReturn(Optional.of(coupon));
        final Optional<Coupon> result = couponServiceImpl.findOne(1L);
        assertTrue(result.isPresent());
        verify(this.couponRepository).findById(anyLong());
    }

    @Test
    void testDelete() {
        couponServiceImpl.delete(1L);
        final Optional<Coupon> optionalCoupon = this.couponServiceImpl.findOne(1L);
        assertTrue(optionalCoupon.isEmpty());
        verify(couponRepository).deleteById(anyLong());
        verify(couponRepository).findById(anyLong());
    }

    @Test
    void saveShouldWorkProperly() {
        final Coupon coupon = easyRandom.nextObject(Coupon.class);
        when(this.couponRepository.save(any(Coupon.class))).thenReturn(coupon);

        final Coupon savedCoupon = this.couponServiceImpl.save(coupon);
        assertNotNull(savedCoupon);
        verify(this.couponRepository).save(any(Coupon.class));
    }

    @Test
    void saveShouldThrowException() {
        final DataIntegrityViolationException exception = new DataIntegrityViolationException("Entity exists in database");
        final Coupon coupon = easyRandom.nextObject(Coupon.class);
        when(this.couponRepository.save(any(Coupon.class))).thenThrow(exception);

        DataIntegrityViolationException assertThrows = assertThrows(
                DataIntegrityViolationException.class,
                () -> this.couponServiceImpl.save(coupon)
        );

        verify(this.couponRepository).save(any(Coupon.class));
        assertNotNull(assertThrows);
        assertNotNull(assertThrows.getMessage());
        assertTrue(assertThrows.getMessage().contains("Entity exists in database"));
    }

    @Test
    void findByCouponCodeAndActiveIsTrueShouldFindProperCoupon() {
        final Optional<Coupon> optionalCoupon = this.couponServiceImpl.findByCouponCodeAndActiveIsTrue(COUPON_CODE);
        assertTrue(optionalCoupon.isPresent());
        verify(this.couponRepository).findByCouponCodeAndActiveIsTrue(anyString());
    }

    @Test
    void findByCouponCodeAndActiveIsTrueShouldNotFindAnyCoupon() {
        final Optional<Coupon> optionalCoupon = this.couponServiceImpl.findByCouponCodeAndActiveIsTrue("ANOTHER_CODE");
        assertTrue(optionalCoupon.isEmpty());
        verify(this.couponRepository).findByCouponCodeAndActiveIsTrue(anyString());
    }

    @Test
    void findAllByDiscountTypeCodeAndActiveIsTrueShouldWorkProperly() {
        final List<Coupon> coupons = this.couponServiceImpl.findAllByDiscountTypeCodeAndActiveIsTrue(COUPON_CODE);
        assertFalse(coupons.isEmpty());
        verify(this.couponRepository).findAllByDiscountType_DiscountTypeCodeEqualsIgnoreCaseAndActiveIsTrue(anyString());
    }

    @Test
    void findByCouponCodeShouldWorkProperly() {
        final Optional<Coupon> optionalCoupon = this.couponServiceImpl.findByCouponCode(COUPON_CODE);
        assertTrue(optionalCoupon.isPresent());
        verify(this.couponRepository).findByCouponCode(anyString());
    }
}

Excerpt of the full test suite for CouponServiceImplTest

What have we done in the previous test suite to achieve the a report with full succes?. We added verifications, and assertions to ensure that behaviour for our tests is correct. This way, we solved the different kind of mutants present in the report.

And now this is how our CouponServiceImpl report looks like:

Improved PIT report.

As you can see in the new report, after killing the mutants and dealing with the NO_COVERAGE tests, we have increased our package report statics.

Conclusions.

Having concerned all the above points, we can notice the flaws of only relying in the code coverage as metric. Evergreen tests can be present, which doesn't means that we are testing properly our software components. Thanks to the evolution of mutation tests, and within the combination of the code coverage metric, we can assure good quality software.

Source code for this example, can be found here.

DEV Community: JesúsB

(Update: NgRx Signal Store Enhancements) Mastering State Management with NgRx Signal Store in Angular 🚀

Key Changes and Additions

1. Introduction of withProps

2. Improved Dependency Injection

3. Enhanced Method Definitions

4. Consistency with NgRx Documentation

Summary of Benefits

Conclusion

Mastering State Management with NgRx Signal Store in Angular 🚀

What is NgRx Signal Store?

Setting Up NgRx Signal Store

Creating a Signal Store

Computed Properties

State Modifications

Using the Store in Components

Benefits of NgRx Signal Store

Conclusion

Boosting Angular Performance: @defer, Lazy Loading, and Core Web Vitals

🔍 Understanding Core Web Vitals

🧩 The Power of @defer

🎯 Impact on Core Web Vitals

🏋️ Lazy Loading: The Perfect Companion

🎯 Core Web Vitals impact

🔧 Practical Implementation Tips

Prioritize Above-the-fold Content

Smart Prefetching

Lazy Load Feature Modules

Use Standalone Components

🎭 Real-world Scenario: Podcast Streaming App

📊 Measuring the Impact

🏁 Conclusion

DON'T MISS: Your angular forms strongly typed based on your interface :rocket:

📌 Strongly Typed Forms in Angular Without Duplicating Interfaces

David Garcia ・ Feb 4

Architecting Angular Applications: A Case Study in Scalable and Maintainable Design 🚀

Who Is This Article For? 👨‍💻👩‍💻

The Folder Structure: A Foundation for Clarity 🗂️

Why This Structure? 🤔

Components: The Building Blocks 🧱

Services: The Data Management Layer 🗄️

Models: Defining the Shape of Data 📐

Adapters: Bridging External and Internal Data Structures 🌉

Store: Managing Application State with NgRx SignalStore 🚦

Why NgRx SignalStore? 🤔

Benefits of This Architecture ✨

Conclusion 🎉

Streamlining Data Flow in Angular: The Power of the Adapter Pattern 🔄

Mastering the Container-Presenter Pattern in Angular: A Deep Dive

Modernizing Angular: Embracing Fetch API for Better Performance and Security

New in Angular: Bridging RxJS and Signals with toSignal!

Modern Testing Practices in Angular: From Unit to Integration Testing

Introduction to Modern Testing in Angular

Defining Testing Terms and Types

Traditional Unit Testing in Angular

Introduction to Integration Testing

Comparing Unit Tests and Integration Tests

Unit Tests

Integration Tests

Modern Testing Models and Recommendations

The Testing Trophy Model 🏆

Insights from the Angular Team on Testing Practices

Modernizing Angular: What's New in Angular 19

1. Incremental Hydration: A Game Changer for SSR

2. Event Replay: Ensuring Smooth User Interactions

3. Route-Level Render Mode: Fine-Grained Control Over Rendering

4. Hot Module Replacement (HMR) Just Got Instant

5. Zoneless Support: Continued Evolution

6. Linked Signals: Reactive State with Contextual Awareness

7. Angular Material Upgrades

8. Migration Scripts for Signals

9. Enhanced Content Security Policy

10. The Future of Testing in Angular

Wrapping Up

PIT, a mutation testing system for Java.

Is it not code coverage enough?.

Mutation testing.

Mutation testing example.

Killing the mutants...

Conclusions.

1. Introduction of `withProps`

🧩 The Power of `@defer`