Balancing Motherhood, Career, and Self: A Therapist’s Mission to Empower Women

Since becoming a therapist, I’ve realized the immense power of combining my newfound love for therapy with my extensive experience as a software engineer. My mission is to help women who live in constant doubt—doubt about whether they can be loving mothers, successful professionals, and fulfilled individuals all at once. Through mentoring and coaching, I guide women toward a life where they can thrive in all their roles without compromising their identity or happiness.

Why Women Struggle with Balance

As a therapist and a mother of five children, I’ve lived the challenges many women face daily. The pressure to excel in every role can leave you feeling like you’re constantly falling short. For many, this leads to doubt, guilt, and even burnout.

• “Am I spending enough time with my children?”
• “Is my career taking too much away from my family?”
• “Will I ever feel like I’m enough in any area of my life?”

These are the questions I hear from women every day—and ones I’ve asked myself in my journey.

Combining Therapy and Technology: A Unique Approach

With over 25 years as a software engineer, I’ve honed problem-solving, analytical thinking, and systems design—skills I now apply in my work as a therapist and coach. Just as technology solutions require careful planning and optimization, so do our lives.

Here’s how I bring this unique blend of expertise to my work with women:

1. Identifying Patterns
   Using a systematic approach, I help women uncover the beliefs and habits that keep them stuck in cycles of doubt and stress.
2. Breaking Down Goals
   Just as I would design software solutions step by step, I guide my clients in breaking down their ambitions into achievable, actionable goals.
3. Building Confidence
   Through mentoring, I help women see their worth beyond the roles they play, empowering them to embrace both their professional aspirations and their personal lives.

Mentoring and Coaching: My Mission to Empower Women

My work goes beyond therapy. I provide mentoring and coaching to women who want to reclaim their sense of self and live a life of purpose and fulfillment. My mission is to create a community of women who support each other in redefining what success looks like.

• For the mom who feels torn between family and career, I offer strategies to create harmony in both.
• For the professional struggling with imposter syndrome, I help build confidence and clarity.
• For the woman who feels she’s lost herself, I provide the tools to reconnect with her passions and dreams.

A Life Where You Can Thrive

The idea that you must choose between being a present mother and a successful professional is outdated. You can have both, but it requires intention, self-compassion, and a willingness to redefine balance.

Through therapy, mentoring, and coaching, I help women step out of doubt and into confidence. Whether it’s through one-on-one sessions or group workshops, I guide women toward living authentically and embracing their full potential.

Are You Ready to Reclaim Your Life?

If you’re struggling to find harmony between motherhood, career, and self, I’m here to help. Together, we’ll explore your unique challenges and create a personalized path to a life where you feel fulfilled, confident, and whole.

You don’t have to navigate this journey alone. Let’s work together to turn your doubt into strength and your dreams into reality.

Because you deserve to thrive—not just as a mother or a professional, but as you.

Introducing resource

Angular 19 brings an exciting addition to its toolkit: the Resource API. This API is designed to simplify asynchronous data fetching and state management, making it more declarative and easier to integrate into Angular’s reactive ecosystem.

In this blog, we’ll explore:

• The benefits of the Resource API
• How it compares to traditional HttpClient implementations
• A complete example using products data, showcasing filtering by category with linkedSignal

What is the Resource API?

The Resource API leverages Angular’s reactivity model to provide:

• Declarative data fetching: Define and manage resources with minimal boilerplate.
• Automatic state management: Built-in handling of loading, errors, and data updates.
• Reactive signals: Seamless synchronization with Angular’s signal and linkedSignal.

How Does It Compare to the Traditional Approach?

The Old Way

In pre-Angular 19 applications, data was often fetched using HttpClient within services, requiring manual state management. Here’s an example:

// Old service implementation
getProducts(): Observable<Product[]> {
  return this.http.get<Product[]>('https://api.example.com/products');
}

// Old component implementation
this.productService.getProducts().subscribe({
  next: (data) => { this.products = data; this.isLoading = false; },
  error: (err) => { this.error = err.message; this.isLoading = false; }
});

Drawbacks

1. Manual State Management: Developers had to handle loading, errors, and data updates manually in every component.
2. Boilerplate Code: Each service and component required repetitive code for fetching data and managing states.
3. Complexity with Derived States: Filtering and transforming data often required separate streams or additional logic.
4. Inconsistent Practices: Different developers might manage states differently, leading to inconsistent patterns across the codebase.

The New Way with Resource API

With the Resource API, the repetitive parts of state management are handled automatically:

products = resource({
  loader: async () => {
    const response = await fetch('https://api.example.com/products');
    if (!response.ok) {
      throw new Error('Failed to fetch products');
    }
    return response.json();
  },
});

Why It’s Better Long Term

1. Declarative Syntax: The Resource API makes data fetching and state management part of the Angular reactivity model. Developers define what data they need and how it should react to changes, and Angular handles the rest.
2. Built-In State Management: Automatic handling of loading, error, and data states simplifies component logic.
3. Derived State with Signals: The seamless integration with linkedSignal allows for effortless creation of derived states (e.g., filtering products by category).
4. Reduced Boilerplate: Say goodbye to repetitive loading/error handling code in every component.
5. Consistency: Provides a standard way to manage data across the application, making it easier to onboard new developers or refactor code.
6. Future-Ready: The Resource API aligns with Angular’s long-term strategy of reactive, signal-based development, ensuring compatibility and smoother upgrades in the future.

Building a Product List with the Resource API

Let’s dive into a practical example: fetching and displaying products with filtering by category.

Service Implementation

Here’s how to set up the Resource API in your ProductService:

import { Injectable, signal, resource } from '@angular/core';
import { Product, Response } from './Product';

@Injectable({
  providedIn: 'root',
})
export class ProductService {
  private apiUrl = 'https://dummyjson.com/products';

  // Signal to trigger the resource loader
  private trigger = signal<void>(undefined);

  // Resource to fetch products
  products = resource({
    request: () => this.trigger,
    loader: async () => {
      const response = await fetch(this.apiUrl);
      if (!response.ok) {
        throw new Error('Failed to fetch products');
      }
      const data = response.json() as Promise<Response>;
      return (await data).products;
    },
  });

  // Method to reload products
  reload() {
    this.trigger.set(undefined);
  }
}

Component with Linked Signals

In the component, linkedSignal is used to manage derived states, like the list of categories and filtered products.

import { Component, effect, linkedSignal, signal } from '@angular/core';
import { ProductService } from '../product.service';

@Component({
  selector: 'app-product-list',
  templateUrl: './product-list.component.html',
  styleUrls: ['./product-list.component.css'],
})
export class ProductListComponent {
  productsResource = this.productService.products;
  selectedCategory = signal<string>('all');

  categories = linkedSignal(() => {
    if (!this.productsResource.value()) return [];
    return Array.from(
      new Set(
        this.productsResource.value()?.map((product) => product.category)
      )
    );
  });

  filteredProducts = linkedSignal(() => {
    const category = this.selectedCategory();
    if (category === 'all') return this.productsResource.value();
    return this.productsResource.value()?.filter(
      (product) => product.category === category
    );
  });

  constructor(private productService: ProductService) {}

  selectCategory(e: any) {
    this.selectedCategory.set(e.target.value);
  }

  reload() {
    this.selectedCategory.set('all');
    this.productService.reload();
  }
}

The Benefits in Action

1. Automatic State Management: Loading, data, and error states are built into the Resource API.
2. Simplified UI Logic: The use of linkedSignal ensures that the UI automatically updates when data or user selections change.
3. Consistency Across Features: The same declarative pattern can be used for other data resources, ensuring uniformity across the app.

Conclusion

Angular 19’s Resource API is a significant step forward for Angular developers. By combining declarative data fetching with reactive signals, it provides:

• Cleaner code
• Enhanced maintainability
• A more consistent developer experience

When compared to the traditional approach, the Resource API not only reduces boilerplate but also aligns with Angular’s vision for reactive, signal-driven development, ensuring its relevance for years to come.

If you’re still using the old way, now is the time to embrace the future with Angular 19. What do you think about the Resource API? Let’s discuss in the comments below!

Checkout complete code example here: https://github.com/kategable/stackblitz-starters-linkedSignal

and StackBlitz: https://stackblitz.com/~/github.com/kategable/stackblitz-starters-linkedSignal

get more Angularv19 here https://blog.angular.dev/meet-angular-v19-7b29dfd05b84

Exploring Angular’s linkedSignal: Enhancing Signal Reusability

In Angular applications, managing state and reactivity often involves tools like BehaviorSubject from RxJS. With the advent of signals, particularly linkedSignal, Angular provides a declarative and more Angular-native approach to handling dynamic state transformations.

Let’s build a product filtering example to see how linkedSignal can simplify state management and potentially replace BehaviorSubject.

In this post, we’ll explore what linkedSignal is, its benefits, how it can replace BehaviorSubject in many use cases, and how you can implement it in your Angular applications.

What is linkedSignal?

The linkedSignal function allows you to create a signal whose value is derived from other existing signals. Unlike computed signals that focus on recalculating values reactively, linkedSignal is more tailored for situations where the new signal’s lifecycle and reactivity are closely tied to another signal or context.

This makes linkedSignal a perfect choice when:

• You need to extend or transform the behavior of an existing signal.
• You want to maintain a scoped reactive context within your application.

Why Replace BehaviorSubject with Signals?

Traditionally, Angular developers have relied on BehaviorSubject from RxJS for state management, such as holding and propagating reactive data. While powerful, BehaviorSubject has limitations that linkedSignal can address:

1. Boilerplate Reduction

With BehaviorSubject, you often have to write additional boilerplate for initialization, subscriptions, and updates:

const subject = new BehaviorSubject<number>(0);
subject.next(5);
subject.subscribe(value => console.log(value));

In contrast, linkedSignal provides a more concise and declarative API:

const baseSignal = signal(0);
const linked = linkedSignal(() => baseSignal() * 2);
console.log(linked());

2. Declarative State Management

linkedSignal eliminates the need for manual subscription management, reducing the risk of memory leaks and simplifying code structure. It’s purely declarative, meaning dependencies and updates are handled automatically.

3. Tight Integration with Angular

Unlike BehaviorSubject, which is an external library feature, linkedSignal is natively supported in Angular, ensuring seamless integration with other Angular features like templates and change detection.

Scenario: Product Filtering

Imagine you have a list of products, and the user can filter them by category. Using linkedSignal, we can create a reactive filtered list that updates automatically whenever the category or product list changes.

import { Component, signal, linkedSignal } from '@angular/core';

@Component({
  selector: 'app-product-filter',
  standalone: true,
  template: `
    <h2>Product Filter</h2>
    <div>
      <label>Filter by Category:</label>
      <select [value]="selectedCategory()" (change)="selectCategory($event.target.value)">
        <option value="all">All</option>
        <option *ngFor="let category of categories" [value]="category">
          {{ category }}
        </option>
      </select>
    </div>

    <div>
      <h3>Products</h3>
      <ul>
        <li *ngFor="let product of filteredProducts()">
          {{ product.name }} - {{ product.category }}
        </li>
      </ul>
    </div>
  `,
})
export class ProductFilterComponent {
  // Base signal for the list of products
  products = signal([
    { name: 'Laptop', category: 'Electronics' },
    { name: 'Headphones', category: 'Electronics' },
    { name: 'Sofa', category: 'Furniture' },
    { name: 'Table', category: 'Furniture' },
    { name: 'T-shirt', category: 'Clothing' },
  ]);

  // Signal for selected category
  selectedCategory = signal<string>('all');

  // Derived signal for filtering products based on the selected category
  filteredProducts = linkedSignal(() => {
    const category = this.selectedCategory();
    const allProducts = this.products();
    return category === 'all'
      ? allProducts
      : allProducts.filter(product => product.category === category);
  });

  // Generate a list of unique categories from the products
  get categories() {
    return Array.from(new Set(this.products().map(product => product.category)));
  }

  // Update the selected category
  selectCategory(category: string) {
    this.selectedCategory.set(category);
  }
}

Component Code

https://stackblitz.com/~/github.com/kategable/stackblitz-starters-linkedSignal?file=src/app/demo/demo.component.ts

How It Works

1. Signal Initialization:
   • products contains a static list of products.
   • selectedCategory holds the currently selected category.
2. Linked Signal:
   • filteredProducts derives its value based on products and selectedCategory. It automatically recalculates when either signal changes.
3. Reactivity in Action:
   • When the user selects a category, the filteredProducts signal updates the displayed list of products dynamically.
4. If we used BehaviorSubject:
   • Set up a subject,
   • add pipe for transformations,
   • add manual subscriptions or async pipe.
5. With linkedSignal:
   • Avoid subscriptions entirely.
   • Use Angular’s built-in reactivity for value updates.
   • Keep the code cleaner and more concise.

Benefits of This Approach

1. Dynamic Updates: Any change in the product list or selected category immediately updates the filtered list.
2. Code Clarity: The filtering logic is encapsulated within the linkedSignal, making it reusable and easier to test.
3. Performance: Signals ensure efficient updates with minimal recalculations.

When to Use linkedSignal Instead of BehaviorSubject

Consider using linkedSignal when:

• You are managing state within Angular components or services.
• You want a simpler, Angular-native alternative to RxJS subjects.
• The logic requires automatic dependency tracking and updates.

However, if you’re managing streams from external sources (e.g., WebSocket connections or complex asynchronous workflows), BehaviorSubject or other RxJS operators may still be more appropriate.

Conclusion

Angular’s linkedSignal simplifies state management by allowing you to derive signals dynamically. This product filter example demonstrates how you can build responsive and dynamic applications with ease.

Give it a try in your next Angular project, and let me know if you want more examples or use cases!

Code link:

git clone https://github.com/kategable/stackblitz-starters-linkedSignal.git

stackblitz – https://stackblitz.com/~/github.com/kategable/stackblitz-starters-linkedSignal?file=src/app/demo/demo.component.ts

get more Angularv19 here https://blog.angular.dev/meet-angular-v19-7b29dfd05b84

Streamlining Application Development: Nx Monorepo’s Transformative Impact for Angular Developers.

In the fast-paced world of enterprise software development, I discovered Nx Monorepo as an Angular developer when I worked on a team converting AngularJs project to Angular, the latest version 14. That was my first time working with nx on a production code, and I was so excited because I learned it in my free time and was eager to see all the benefits it would provide. This tool became a game-changer in streamlining the project, ensuring code quality, consistency, and developer satisfaction. It’s a transformative step that streamlines development, unites teams, and enhances efficiency. Do you want to be the hero on your team? Keep reading, and you will have all the tools to get your team to be on top of their development game.

In this article, we’ll explore how Nx Monorepo facilitates Angular development and provides practical steps for you to get started. But that’s not all. We’ll also delve into the challenges I faced when introducing Nx to my team, offering insights into how to move your team toward its adoption. Additionally, we’ll discuss the advantages of having this skill set, not just for your projects but also for your career growth. Join me on this journey to revolutionize your approach to building software solutions and empower your team for the future.

Let me begin by introducing myself. I’m Kate, and I’ve been involved in enterprise software development for the past 25 years. My time consulting at HeroDevs has been a highlight of my career, and I take pride in being a part of the team here. I specialize in web development using the Angular framework, although I am a full-stack developer.

New Team

When I joined my current project, it was already well into the advanced stages of development, with the beta version on the horizon. The team handed me a set of urgent user stories, and the deadline was rapidly approaching. In our current setup, each team operates within its own dedicated repository, with some teams already successfully utilizing Nx.

We’re currently immersed in a micro-frontend architecture project, creating a web component using the @angular-elements library. In the initial stages, we encountered a significant challenge: our unit-test coverage was alarmingly low. We found ourselves heavily dependent on the QA group, which isn’t an ideal situation. Our primary objective was to boost our unit test coverage to an ambitious 80%. However, given that a substantial portion of our code remained untested at a mere 30%, we had no choice but to allocate an entire sprint solely to the task of writing unit tests. Despite our dedicated efforts during that sprint, we still fell short of reaching the 80% target.

Let us get started with Nx

After our second production release, a significant challenge emerged: the integration of a substantial new feature. I was tasked with enhancing our approach to state management and component architecture. Simultaneously, we needed to plan a strategy for facilitating bi-directional communication in our micro-frontend setup.

One of my favorite features of Nx is the caching of tasks. Executing commands like build and test can be resource-intensive when working with a large codebase. However, Nx employs a computational cache, ensuring it doesn’t unnecessarily rebuild the same code. With a limited number of sprints available before our upcoming release, I began advocating for the adoption of Nx within our team.

Making the team believe it’s the right thing

The initial step involved asking them if they were prepared to learn about the benefits of integrating Nx into our repository.
I created a task with the benefits of using nx. My primary goal is to ensure that other team members feel comfortable integrating this new and complex technology, thus minimizing potential adverse effects.

**1. Standardized Libraries and Applications:** 
 Using a mono repo approach, you can ensure that all repository applications use the same versions of libraries like Angular and, RxJS, NgRx. This helps maintain consistency and reduces the chances of compatibility issues arising when different projects use different library versions. With the new feature’s introduction, we plan to incorporate additional libraries. This strategic move allows us to run independent unit tests on the freshly added code, thus reaching the goal of 80% coverage, seamlessly integrating NgRx for state management, and introducing reusable code components essential for integration purposes. Moreover, we’ll extend our project by including a new app designed for micro frontend integration within our workspace, thus laying the foundation for enhanced code reuse and collaboration.

**2. Computational Cache for Building Artifacts:** 
 Nx provides caching mechanisms that can significantly speed up the build process. Cached artifacts can be reused during local builds and within the PR/main processes, reducing build times and improving developer productivity.

**3. Dependency Graph and Management:** 
 Nx provides tools to visualize the dependency graph between different projects, making it easier to understand how different components are interconnected. This visibility helps in making informed decisions about code changes and minimizes unintended side effects.

**4. Better Developer Experience:** 
 Nx workspace tools offer features like code generation, code linting, testing, and more, all integrated within the mono repo setup. This comprehensive tooling enhances the overall developer experience and makes it easier to manage and develop different parts of the project.

Let the work begin 

I was thrilled to kickstart our Nx journey. One of my initial tasks was to set up the workspace, which, fortunately, didn’t pose too many challenges. The only missing piece in our project was ESLint, which did require some time and effort to address. However, I welcomed the challenge, and by the end of the day, we had made significant progress.

As we continue our journey of adopting Nx, local caching remains my favorite feature.

 I hope this article has been helpful, especially for those of you dealing with complex architectures, particularly when developing web components and creating multiple bundles for integration. Nx proves to be a valuable solution.

So far, we’ve developed two applications and five libraries, achieving a remarkable 85% to 100% unit test coverage for all new code. We’re still exploring the full range of possibilities that Nx offers, and I’ll be delighted to provide updates as we make progress.

Conclusion 

I’d like to emphasize that Nx isn’t limited to Angular; it’s also prominent in the React world. While it’s particularly popular in multi-team environments, my experience showcases another compelling use case. 

Having this versatile tool in your toolbox can significantly boost your career prospects. Consider diving deeper into Nx, and advocate for its use in your workplace or project, and you’ll discover that it could be the key to unlocking your next career advancement. Thank you for joining me on this Nx journey, and here’s to the exciting opportunities it brings!

This is my attempt to help a new developer understand how nested arrays opperate.

A nested array can be thought of like a set of nested dolls, where each doll is contained within another doll.

[
  [1, 2, 3],
  [4, 5, 6],
  [7, 8, 9]
]

This array can be thought of as a set of three nested dolls, where the first doll contains the array [1, 2, 3], the second doll contains the array [4, 5, 6], and the third doll contains the array [7, 8, 9].

Each of these inner arrays is itself an array, and so we can think of them as smaller dolls contained within the larger dolls. For example, the first doll (which contains the array [1, 2, 3]) can be thought of as containing three smaller dolls, one for each element in the array.

We can continue this process of nesting to any level. For example, we could have an array like this:

For example, consider the following array:

[
  [
    [1, 2],
    [3, 4]
  ],
  [
    [5, 6],
    [7, 8]
  ]
]

This array can be thought of as a set of two nested dolls, where the first doll contains the array [[1, 2], [3, 4]] and the second doll contains the array [[5, 6], [7, 8]]. Each of these inner arrays is itself an array, and so we can think of them as smaller dolls contained within the larger dolls. The innermost arrays ([1, 2] and [3, 4]) can be thought of as the smallest dolls in the set.

Here is an example of how you can search for elements within an array in JavaScript:

const numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9];

// Search for the number 3 in the array
const index = numbers.indexOf(3);
console.log(index);  // Output: 2 (the index of 3 in the array)

// Search for the number 10 in the array
const index = numbers.indexOf(10);
console.log(index);  // Output: -1 (10 is not in the array)

In this example, we have an array of numbers called numbers. We use the indexOf() method to search for the number 3 in the array. This method returns the index of the element in the array, or -1 if the element is not found.

So, when we search for the number 3, the indexOf() method returns 2, which is the index of 3 in the numbers array. When we search for the number 10, the indexOf() method returns -1, indicating that 10 is not in the array.

There are also other ways to search for elements within an array in JavaScript. For example, you can use the includes() method to check if an element is present in an array:

const numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9];

// Check if the array includes the number 3
const includesThree = numbers.includes(3);
console.log(includesThree);  // Output: true

// Check if the array includes the number 10
const includesTen = numbers.includes(10);
console.log(includesTen);  // Output: false

Here is an example of how you can search for elements within a nested array in JavaScript:

const numbers = [[1, 2, 3], [4, 5, 6], [7, 8, 9]];

// Search for the number 3 in the nested array
for (const innerArray of numbers) {
  const index = innerArray.indexOf(3);
  if (index !== -1) {
    console.log(`Found 3 at index ${index} of inner array ${innerArray}`);
  }
}

// Output: "Found 3 at index 2 of inner array [1, 2, 3]"

In this example, we have a nested array called numbers, which contains three inner arrays: [1, 2, 3], [4, 5, 6], and [7, 8, 9]. We use a for...of loop to iterate over each of the inner arrays, and we use the indexOf() method to search for the number 3 within each inner array.

If the indexOf() method returns a value other than -1, it means that 3 was found within the inner array. In this case, we log a message indicating the index at which 3 was found and the inner array in which it was found.

You can use a similar approach to search for elements within nested arrays at any level of nesting. For example, you could use a nested loop to iterate over each element within each inner array, and so on.

Here is an example of how you can use a recursive function to search for an element within a nested array in JavaScript:

function findElement(element, array) {
  for (const item of array) {
    if (Array.isArray(item)) {
      // If the current item is an array, recursively search for the element within that array
      const result = findElement(element, item);
      if (result) {
        // If the element was found, return the result
        return result;
      }
    } else if (item === element) {
      // If the current item is the element we are searching for, return its index
      return array.indexOf(item);
    }
  }

  // If the element was not found, return null
  return null;
}

const numbers = [[1, 2, 3], [4, 5, [6, 7]], [8, 9]];

// Search for the number 7 in the nested array
const index = findElement(7, numbers);
console.log(index);  // Output: "Found 7 at index [1, 1, 1]"

In this example, we have defined a function called findElement() that takes an element and an array as arguments. The function uses a for...of loop to iterate over the elements in the array, and it checks whether each element is itself an array.

If the element is an array, the function calls itself recursively with the element and the array as arguments. This process continues until an element is found that is not an array, at which point the function checks whether the element is the element we are searching for. If it is, the function returns the index of the element within the array. If the element is not found, the function returns null.

In the example above, we use the findElement() function to search for the number 7 within the nested array numbers. The function returns [1, 1, 1], which indicates that 7 was found at index 1 within the second inner array, which is itself at index 1 within the numbers array.

Here is an example of how you can use the flat() method to flatten a nested array and search for an element within it using the indexOf() method, which can provide a faster search for large arrays:

const numbers = [[1, 2, 3], [4, 5, [6, 7]], [8, 9]];

// Flatten the nested array using the flat() method
const flatNumbers = numbers.flat();

// Search for the number 7 in the flattened array
const index = flatNumbers.indexOf(7);
console.log(index);  // Output: 5 (the index of 7 in the flattened array)

In this example, we have a nested array called numbers that contains three inner arrays: [1, 2, 3], [4, 5, [6, 7]], and [8, 9]. We use the flat() method to flatten the array and create a new, one-dimensional array called flatNumbers.

We can then use the indexOf() method to search for the number 7 within the flattened array. This method returns the index of the element in the array, or -1 if the element is not found. In this case, the method returns 5, which is the index of 7 in the flattened array.

Using the flat() method and the indexOf() method can provide a faster search for large arrays, as the flat() method flattens the array in place and the indexOf() method performs a linear search through the array.

It is important to use optimal algorithm for searching nested arrays.

Using an optimal algorithm for searching nested arrays is important because it can help to reduce the time and computational resources required to find an element within the array. This can be particularly important when working with large arrays, as the time and resources required to search the array can increase significantly with the size of the array.

There are several algorithms that can be used to search nested arrays, each with its own trade-offs in terms of efficiency and complexity. For example, a linear search through the array (such as using the indexOf() method) can be relatively simple to implement, but it may not be the most efficient option for large arrays. On the other hand, more complex algorithms, such as binary search, can be more efficient but may require more implementation effort.

It is generally a good idea to choose an algorithm that is both efficient and easy to implement, depending on the specific requirements of your application. For example, if you are working with a small array that does not need to be searched frequently, a simple linear search may be sufficient. However, if you are working with a large array that needs to be searched frequently, you may want to consider using a more efficient algorithm.

I just finished implementing data polling using ngrx effects. For those unfamiliar with ngrx, it is a popular library for implementing the Redux pattern in Angular applications.

To implement data polling with ngrx effects, you can create an effect that listens for a specific action, such as a POLL_DATA action. When this action is dispatched, the effect can perform an HTTP request to retrieve the data from a remote server, and then dispatch a new action with the data.

You can use the @Effect decorator to create an effect that listens for specific actions. The @Effect decorator takes an options object as an argument, which allows you to specify the action that the effect should listen for and the effect’s behavior.

For example, you might create an effect that listens for the POLL_DATA action and performs an HTTP request to retrieve the data like this:

@Injectable()
export class PollingEffects {
  pollData$: Observable<Action> = this.actions$.pipe(
    ofType(POLL_DATA),
    switchMap(() =>
      this.http.get('/api/data').pipe(
        map((data) => ({ type: DATA_RECEIVED, payload: data })),
        catchError(() => of({ type: DATA_REQUEST_FAILED }))
      )
    )
  );
}

This effect listens for the POLL_DATA action and then performs an HTTP request using the HttpClient service. If the request is successful, it dispatches a DATA_RECEIVED action with the received data as the payload. If the request fails, it dispatches a DATA_REQUEST_FAILED action.

To ensure that the data is polled at regular intervals, you can use the interval operator from the RxJS library. You can modify the effect above to poll the data every 10 seconds like this:

@Injectable()
export class PollingEffects {
  pollData$: Observable<Action> = this.actions$.pipe(
    ofType(POLL_DATA),
    switchMap(() => interval(10000)),
    switchMap(() =>
      this.http.get('/api/data').pipe(
        map((data) => ({ type: DATA_RECEIVED, payload: data })),
        catchError(() => of({ type: DATA_REQUEST_FAILED }))
      )
    )
  );
}

In this modified version of the effect, the interval operator is used to emit a value every 10 seconds (10000 milliseconds). The effect then uses the switchMap operator to perform an HTTP request every time the interval emits a value.

To stop the data polling, you can simply dispatch a new action that the effect can listen for and respond to.

For example, you might create a STOP_POLLING action that the effect can listen for and use to stop polling the data. You can modify the effect above to stop polling when the STOP_POLLING action is dispatched like this:

@Injectable()
export class PollingEffects {
  pollData$: Observable<Action> = this.actions$.pipe(
    ofType(POLL_DATA),
    switchMap(() =>
      interval(10000).pipe(takeUntil(this.actions$.pipe(ofType(STOP_POLLING))))
    ),
    switchMap(() =>
      this.http.get('/api/data').pipe(
        map((data) => ({ type: DATA_RECEIVED, payload: data })),
        catchError(() => of({ type: DATA_REQUEST_FAILED }))
      )
    )
  );
}

In this modified version of the effect, the takeUntil operator is used to stop the data polling when the STOP_POLLING action is dispatched. The takeUntil operator takes an observable as an argument and completes the source observable (in this case, the interval observable) when the argument observable emits a value.

To use this modified effect, you can dispatch the POLL_DATA action to start polling and the STOP_POLLING action to stop polling.

To create a unit test for the data polling effect using the TestScheduler from the RxJS library, you can use the following steps:

First you have to modify your effect to use asyncScheduler like this:

@Injectable()
export class PollingEffects {
  pollData$: Observable<Action> = this.actions$.pipe(
    ofType(POLL_DATA),
    switchMap(() =>
      interval(10000, asyncScheduler).pipe(
        takeUntil(this.actions$.pipe(ofType(STOP_POLLING)))
      )
    ),
    switchMap(() =>
      this.http.get('/api/data').pipe(
        map((data) => ({ type: DATA_RECEIVED, payload: data })),
        catchError(() => of({ type: DATA_REQUEST_FAILED }))
      )
    )
  );
}

In this modified version of the effect, the interval operator is called with the asyncScheduler as the second argument. This causes the interval to use the asyncScheduler to schedule its emissions.

The asyncScheduler is a scheduler that schedules work asynchronously, using the JavaScript interval function. This can be useful if you want to simulate a delay in the data polling effect, or if you want to ensure that the effect is run outside the Angular zone.

I hope this helps clarify how to use the asyncScheduler with the data polling effect. Next you will add your unit tests file and follow the steps:

1. Import the TestScheduler from the RxJS library. The TestScheduler is used to control the virtual time in the test;
2. Create an instance of the TestScheduler and set up the test actions and expected results. To do this, you will need to define the actions that the effect should listen for and the expected results of the effect.
3. Set up the dependencies for the effect under test. This will typically include any services or dependencies that the effect uses, such as the HttpClient service. You can use mock implementations of these dependencies to control their behavior in the test.
4. Create an instance of the effect under test and pass in the dependencies.
5. Pass TestScheduler instance into the effect that is under test. This will execute the effect with a virtual timer.

Here is an example of a unit test for the data polling effect using the TestScheduler:

@Injectable()
export class PollingEffects {

    pollData$ = createEffect(() => ({ scheduler = asyncScheduler} = {}) =>
    this.actions$.pipe(
      ofType(POLL_DATA),
      switchMap(() => interval(10000, asyncScheduler).pipe(
        takeUntil(this.actions$.pipe(ofType(STOP_POLLING)))
      )),
      switchMap(() => this.http.get('/api/data').pipe(
        map(data => ({ type: DATA_RECEIVED, payload: data })),
        catchError(() => of({ type: DATA_REQUEST_FAILED }))
      ))
    )
  );

}

To use the createEffect function from the ngrx library with the data polling effect, you can modify the effect like this:

The createEffect function takes a function that returns an observable as an argument, and returns an observable of actions. The function that is passed to createEffect should contain the logic for the effect.

In this modified version of the effect, the createEffect function is used to wrap the logic for the effect in a way that is compatible with the ngrx store. The effect listens for the POLL_DATA action and performs an HTTP request to retrieve the data every 10 seconds (10000 milliseconds) using asyncScheduler. If the request is successful, it dispatches a DATA_RECEIVED action with the received data as the payload. If the request fails, it dispatches a DATA_REQUEST_FAILED action.

I hope this helps clarify how to use the createEffect function with the data polling effect.

Using ngrx effects to implement data polling is a straightforward process. Essentially, you can create an effect that listens for a specific action, such as a POLL_DATA action, and performs an HTTP request to retrieve data from a remote server. The effect can then dispatch a new action, such as a DATA_RECEIVED action, with the received data as the payload.

To stop the data polling, you can simply dispatch a new action, such as a STOP_POLLING action, that the effect can listen for and use to stop the data polling process.

Unit testing this effect is a bit tricky but you got it!

Hope all the code examples help you!

Hope you enjoyed this article.

Once, in 2022, I had the opportunity to speak at a major Angular conference, ng-conf. I was nervous but excited, as this was a huge opportunity to share my knowledge and expertise with the Angular community.
As the day of the conference approached, I spent hours preparing my presentation and practicing delivery. I wanted to ensure that I could convey ideas clearly and provide valuable insights to the audience.
I was so nervous on the day of the conference, but before getting to the stage, I told myself that I would do my best, no matter what happened. I took a deep breath and began my presentation, explaining the state management features of Angular and how they could be used to build powerful and efficient web applications.

As I presented on stage, I could see my team sitting in the front row, smiling and giving me encouraging nods. I felt a surge of confidence knowing that they were there to support me.
During my presentation, I could see my team nodding along, clearly impressed by my knowledge and expertise. I felt grateful to have such a supportive team behind me.
After my presentation, my team came up to me and congratulated me on a job well done. They praised my hard work and dedication, and I felt proud to be part of such a supportive and talented team.
Overall, having my team there to support me made the experience of speaking at the conference even more special and memorable. I am grateful for their support and encouragement, and I know that I couldn’t have done it without them!

The audience listened intently, nodding along as I spoke. I even had some jokes that made people laugh. I could see that they were interested in what I had to say, and I felt a sense of pride and accomplishment as I finished my presentation.
After the conference, I received many positive comments and feedback from attendees impressed by my knowledge and expertise.

The best feedback I got was from other women who were inspired to see a mother of 5 children on the biggest stage of her life giving a presentation on a very technical subject. They told me, “we know that it’s possible now; if you did it, then any woman can.”

I felt grateful for the opportunity to speak at the conference and inspire women, and I was already looking forward to the next one.

As a woman in the tech industry, I am well aware of the challenges and obstacles that many women face when pursuing careers in technology and programming. That’s why I hope to inspire more women to become programmers through my work and my involvement in the Angular community.
I believe that the tech industry would benefit greatly from having more diversity and inclusion, and I believe that women have a lot to offer in terms of their skills and perspectives.
I want to show other women that it is possible to succeed in the tech industry, and that they can overcome any obstacles and challenges that they may face along the way.

My mission is to help create a more diverse and inclusive tech industry by having more women who code.

Sharing data in the Angular application

When it comes to sharing data between components in an Angular application we have to remember that there more than one right way to do it!

Let’s go over some assumptions, rules, and considerations for this article.

Consider: Follow a container presenter pattern. Check out my video on this here.

Your components have as little responsibility as possible; whether it is to get data from the server or just display it.

You create dumb components whenever possible.

You keep your dependency injections in the components to a minimum.

You abstract business logic to the services.

Assumptions: You don’t always have the luxury of adding a state management library to your application.

I used NGRX and I know that it is a complex library and if the whole team is not on board to use it, then your code becomes a mish-mash of different approaches.

Get the whole team to commit to a state management library or go with another approach like the one described here.

Rules: Keep application performance at the top of the priority list.

Your code has to be clean and easy to read and maintain.

Say No to bubbling up events.

Here is an example of 3 components that all produce data. They have no access to the data they create. Events bubble up to the app.component.

I want to show you what NOT to do!

checkout StackBlitz:

https://stackblitz.com/github/katesky/messages-sent-app

Next up is code where we will add a service that will manage our data and it will be shared with all of our components.

Use service with a subject

git checkout with-service or go to code here –> new branch

We will create a service that will hold a list of our data in a private BehaviorSubject of type an array of strings.

We will add a public observable of that BehaviorSubject to our service.

Now we can add a function that will mutate our data.

We now have a central area where our data is held.

It can be shared across all of our components and there are no events that have to be emitted up to the parents’ components.

Now that our application is truly reactive we can change out changeDetection to OnPush. More info on it here.

Change template to using async pipe. Read about it here!

We can use data$ in all other components the same way as here:

Checkout Stackblitz with code complete:

https://stackblitz.com/github/katesky/messages-sent-app/tree/with-service

I hope this article was usefull for you.

I was able to show you something new and you will avoid some of the mistakes I made when I got started with Angular.

One of my passions is to be able to inspire mothers to get started in technology sector. I am a programmer with over 20 years of experance in IT.

I am also a mother of 5 children. I hope one day my daughters will be inspired by my story to go into STEM.

Till next time!

Kate Sky.

Angular NGRX enabling DevTools at runtime

In this article, I will cover a problem that I was working on in one of my projects. With help from the NGRX team, I was able to solve it.  Shot-out to @brandontroberts , @tim_deschryver, @AlexOkrushko!

I hope it helps you when using NGRX, and you can also add it as part of your development process. 

Problem:

I wanted to be able to enable DevTools at runtime. The reason I want to do that is to be able to let users report his/her application experience and especially the problems they are experiencing. 

In other words, enable debugging reporting on the fly using NGRX framework.

Solution:

This article will be useful if you love Redux DevTools, but you don’t have them enabled in Production.

You would like to have your application to be able to switch to the reporting mode, even in Production.

I will cover the following steps:

1. Adding a lazy-loaded Feature Module
2. Dispatching an effect to create a StoreDevtoolsModule at runtime
3. Extras:
   1. Use hidden F1 key to enable a link for debugging. 
   2. Enable third party logging/debugging tools  

Implementation:

We start by adding a feature; we will call it ‘debug’.  

It will contain:

1.  debug.action – We will use an NGRX action from this file to dispatch from the component.
2. debug.component. We will use Debug component to load our feature via a new route we will add to app.module. 
3. debug.module – We will lazy-load this module that in the app.module, and it will contain a route to the component
4. app.module – Register a new feature with a lazy-loaded route
5. dev-tools.module – Module that will inject the StoreDevTools to kick-of the Redux tools registration from this module.
6. debug.effect – We will use this NGRX effect to catch an action dispatched. This effect will be responsible for the runt-time enabling of the dev tools.
7. root-store.module – Register new Effect in RootModule
8. app.componet – Add a hiddent button that can be turned visible by F1- hot key

debug.action.ts

Add a new action to be dispatch to the store about the state change.

We prefix the type of the action with the name of the page that will dispatch this action.

import { createAction } from '@ngrx/store';

export const enableDebug = createAction('[Debug Page] enable');

debug.component.ts

Add a new component. If you like, you can keep template and styles inline. Both are not used in this setup, so can easily be excluded.

I have an empty template because its not needed.

When component is loaded it will dispatch an action that will enable DevTools (line 14). Effect is below, I promise!

in terminal:

ng generate component debug--inlineTemplate=true --inlineStyle=true

in new file debug.component.ts:

import { Component, OnInit } from '@angular/core';
import { Store } from '@ngrx/store';
import { RootState } from '../+state/root.selectors';
import { enableDebug } from './debug.actions';

@Component({
  template: ``,
  selector: 'app-debug'
})
export class DebugComponent implements OnInit {
  constructor(private readonly store: Store<RootState>) {}

  ngOnInit(): void {
    this.store.dispatch(enableDebug());
  }
}

debug.module.ts

This module is lazy-loaded so it will be registering the child routes.

debug.module.ts:

import { NgModule } from '@angular/core';
import { DebugComponent } from './debug.component';
import { RouterModule } from '@angular/router';
@NgModule({
  imports: [ 
      RouterModule.forChild([{ path:'',component:DebugComponent}])
  ],
  declarations: [DebugComponent],
  exports: [DebugComponent]

})
export class DebugModule {
  constructor(){}
}

app.module.ts

This module we will add a new route and lazy-load it with a feature module.

This is a code-snipet , so if you want to see full code check out my repository.

{
    path: 'debug',
    loadChildren: () =>
    import('./debug/debug.module').then(
      m => m.DebugModule
    )
      
  },

dev-tools.module.ts

This module will be compiled and created in the effect.

On line 14th you can refresh the tools. I didn’t see much of a difference in value having it execute.

import { NgModule } from '@angular/core';
import { StoreDevtoolsModule, StoreDevtools } from '@ngrx/store-devtools';
@NgModule({
  imports: [
    StoreDevtoolsModule.instrument({
      maxAge: 25, // Retains last 25 states
      logOnly: true
    })
  ]
})
export class DevToolsModule {
  constructor(private storeDevtools: StoreDevtools) {
    // storeDevtools.refresh();
  }
} 

debug.effect.ts

Effect class is responsible for reacting to the action dispatched from the component. It filters out actions that it is subscribing to and when enableDebug is dispatched, effect is using ‘exhaustMat’ operator to make sure that if same action is dispatched it will continue to execute. In other words dropping incoming request.

Next it uses injected compiler object to compile dev-tools.module and creates it on lines 21-24.

Once that is completed, we have devtools enabled and redux tools can be used to track our state changes.

We know that we will have a manual mechanism of turning debugging option on so we can redirect our user back to that location. In this case it’s root of the application or home. So the changeLink action is returned via this effect.

import { Injectable, Compiler, Injector } from '@angular/core';
import { createEffect, Actions, ofType } from '@ngrx/effects';

import * as DebugActions from './debug.actions';
import { exhaustMap } from 'rxjs/operators';
import { DevToolsModule } from './dev-tools-module'; 
import { changeLink } from '../+state/root.actions';

@Injectable()
export class DebugEffects {
  constructor(
    private actions$: Actions,
    private compiler: Compiler,
    private injector: Injector
  ) {}

  debugAction$ = createEffect(() =>
    this.actions$.pipe(
      ofType(DebugActions.enableDebug),
      exhaustMap(async () => {
        const m = this.compiler.compileModuleSync<DevToolsModule>(
          DevToolsModule
        );
        m.create(this.injector); 
        return changeLink({ link: '' });
      })
    )
  );
}

If you checkout my repository you will see that I just imported DevToolsModule into the DebugModule for simplicity. I kept the effect for other use case in Extra#2.

import { NgModule } from '@angular/core';
import { DebugComponent } from './debug.component';
import { RouterModule } from '@angular/router';
import { DevToolsModule } from './dev-tools-module';
@NgModule({
  imports: [ 
      RouterModule.forChild([{ path:'',component:DebugComponent}]),
      DevToolsModule
  ],
  declarations: [DebugComponent],
  exports: [DebugComponent]

})
export class DebugModule {
  constructor(){}
  
}

app.component.html

Add anywhere you would like to include a hidden button. So next time your user is having some unexplainable issues they can hit F1 and it will become visible.

Can you tell I am using material components? So if you this code make sure you import all necessary Modules for Material here.

<button *ngIf="isDebugVisible" (click)="onDebug()"mat-icon-button aria-label="debug">
  <mat-icon>bug_report</mat-icon>
</button>

app.component.ts

Extra #1: As promised I will give this little trick. I added hidden button to help user discover issues and be part of the debugging process.

We will add a function to make our button visible with HostListener, filtering out keys.

Next we will add a button click event that will redirect our user to the lazy-loaded module we just setup.

Remember: user will be redirected back here from the debug.effect?

So we can turn off the button – our devtools are enabled!

  onDebug() {
    this.store.dispatch(changeLink({ link: 'debug' }));
    this.isDebugVisible = false;
  }
  @HostListener('document:keydown', ['$event'])
  keypress(e: KeyboardEvent) {
    if (e.key === 'F1') {
      this.isDebugVisible = true;
    }
  }

Extras #2

If you haven’t heard of LogRocket yet. Let me Introduce you. www.logrocket.com This is a very cool product that you can plugin to the application to see a full path of your user experience with visual snap shots.

How cool is that?

If you follow their instruction it is pretty straight forward to include and get started with in your application.

https://app.logrocket.com/<replace-with-yourcode>/settings/integrations/

It is a paid product, if you exceed the number of requests that are free!

But let see if we can utilize a free version by only enabling the setup from our debug lazy-loaded module dev-tools.module?

update debug.effect.ts

import { Injectable, Compiler, Injector } from '@angular/core';
import { createEffect, Actions, ofType } from '@ngrx/effects';

import * as DebugActions from './debug.actions';
import { exhaustMap } from 'rxjs/operators';
import { DevToolsModule, LOGROCKET_INIT_KEY } from './dev-tools-module';
import * as LogRocket from 'logrocket'; 
import { changeLink } from '../+state/root.actions';

@Injectable()
export class DebugEffects {
  constructor(
    private actions$: Actions,
    private compiler: Compiler,
    private injector: Injector
  ) {}

  debugAction$ = createEffect(() =>
    this.actions$.pipe(
      ofType(DebugActions.enableDebug),
      exhaustMap(async () => {
        const m = this.compiler.compileModuleSync<DevToolsModule>(
          DevToolsModule
        );
        m.create(this.injector);
        LogRocket.init(LOGROCKET_INIT_KEY);
        return changeLink({ link: '' });
      })
    )
  );
}

update dev-tool.module.ts

import { NgModule } from '@angular/core';
import { StoreDevtoolsModule, StoreDevtools } from '@ngrx/store-devtools';
import { USER_PROVIDED_META_REDUCERS } from '@ngrx/store';
import * as LogRocket from 'logrocket';
import createNgrxMiddleware from 'logrocket-ngrx';
import { MetaReducer, State } from '@ngrx/store'; 
import { RootState } from '../+state/root.selectors';
const logrocketMiddleware = createNgrxMiddleware(LogRocket, {});

export const metaReducers: MetaReducer<any>[] = [];

export function getMetaReducers(): MetaReducer<RootState>[] {
  return metaReducers.concat([logrocketMiddleware]);
}
export const LOGROCKET_INIT_KEY = '<replace-with-your-code';

@NgModule({
  imports: [
    StoreDevtoolsModule.instrument({
      maxAge: 25, // Retains last 25 states
      logOnly: true
    })
  ],
  providers: [
  
    {
      provide: USER_PROVIDED_META_REDUCERS,
      useFactory: getMetaReducers
    }
  ]}
)
export class DevToolsModule {
  constructor(private storeDevtools: StoreDevtools) {
    // storeDevtools.refresh();
  }
}

Now that we have this setup, we can see our requests are only feeding into our LogRocket account after we enabled debug!

I hope you enjoyed this article! Tweet you questions or comments here.

I will be glad to connect too!

• Twitter
• Twitter

If you would like to see a repository where I added this implementation, follow this github link:

https://github.com/katesky/saraphan-radio/tree/azure/apps/shell-app/src/app/debug

Angular: front-end from start to MVP

by Kate Sky

I am making this post as the first step in documenting my journey of building an Enterprise application for my side project.

The application is in the process of going towards an MVP.

This application is an “Uber for home services.” 

The reason I had started this project: is to provide a value-based service while practicing and teaching others skills I had acquired over the years.

The objective of this post is to establish a timeline of the application going live from its infancy.

Following is the list of topics that we are going to discuss in this article:

1. Application Stack
2. Architectural decisions
   1. Monorepo with Nx
   2. Domain-Driven Design with Angular
   3. State management with NGRX
   4. Logging with LogRocket
   5. Authentication with Auth0
3. Conclusion
4. Links

1. Application Stack

WEB- Angular
API – .Net Core
DB – SQL server

2. Architectural decisions

For web client, I am using Angular framework.

My goal – to be able to scale the development of this application by having the ability to go from one team to many teams building multiple frontend and backend applications all in the same workspace. 

I chose NX, so developers have a holistic dev experience powered by an advanced CLI (with editor plugins), capabilities for controlled code sharing, and consistent code generation.

Monorepos allow huge enterprise applications to be subdivided into small and maintainable libraries. I followed the best practice from the creators of NX and have added a domain-driven design approach to creating the features. One of the features is the search capability for the providers that are displayed. I added a domain ‘Providers’ it contains the feature store for state management and the infrastructure where service is implemented to call the API.

We need to first define criteria for slicing our application into individual parts and we must establish rules for communication between them.

referenced: https://www.angulararchitects.io/aktuelles/sustainable-angular-architectures-1/

I have added NGRX from the very beginning because I would like to have an ability to replay the user’s trip through the application, and I will be adding LogRocket to view that path. NGRX will also help me write clean reactive components with async pipes. Root store has its own module and is at the root of the application.

Stop guessing why bugs happen. LogRocket lets you replay what users do on your site, helping you reproduce bugs and fix issues faster.

https://logrocket.com/

Since we have 2 features now, we can see that NGRX stores for each feature are located near the domain for each feature’s library. There is separate module for each store to be able to import each feature module lazily.

Users have to register, and for authentication, I picked Auth0. Right now, you can see that authentication is on the root store. I have a login and logout actions that are calling the service to execute the correct code. I am using the service I download from the example provided by auth0. It still needs to be cleaned up. 

I added a component for the callback path need for the login of the authentication. There is a CanActivate guard that is used for components that need an authorized user.

3 . Conclusion

In conclusion, we will go through whats next.

I wanted to get the frontend started first and have a clear user experience throughout the application.

I will add the .net Core API to store the data to the database next.

I deployed code to GitHub pages to be able to get user feedback at the very early stages of this application.

4. Links

Code: https://github.com/katesky/saraphan-radio

Dev version: https://katesky.github.io/saraphan-radio/

Domain: http://saraphanradio.com