DEV Community: Benjamin Arambide

Typing Objects with at Least One Property in TypeScript

Benjamin Arambide — Tue, 27 May 2025 15:29:56 +0000

In TypeScript, there are cases where you want to define a type that ensures an object contains at least one specific property, while allowing any additional properties.

A common example is ensuring an object has a name property, regardless of what else it contains.

Basic Use Case

To specify that an object must have at least a name property:

interface HasName {
  name: string;
}

function greet(obj: HasName) {
  console.log(`Hello, ${obj.name}`);
}

greet({ name: "Alice", age: 30 }); // ✅ Works

Using Inline Types

Instead of declaring a separate interface:

function greet(obj: { name: string }) {
  console.log(`Hi, ${obj.name}`);
}

This also works fine for inline use.

Using Generics with Constraints

If you're working with generics and want to retain the full object type while requiring a name property:

function greet<T extends { name: string }>(obj: T) {
  console.log(`Hi, ${obj.name}`);
}

This keeps the full shape of the passed object available for further use.

Dynamic Check with Type Predicate

Sometimes you receive unknown data and want to ensure it has a name property:

function hasName(obj: any): obj is { name: string } {
  return typeof obj === 'object' && obj !== null && 'name' in obj;
}

Used like:

const data = { name: "Bob", age: 40 };

if (hasName(data)) {
  console.log(data.name); // Safe access
}

Summary

To enforce the presence of a property like name:

✅ Use a basic interface like { name: string }
✅ Use generics for flexibility and type retention
✅ Use type predicates for runtime checks
🔐 TypeScript won't automatically enforce "only one property", but it ensures required keys exist

This pattern is useful in APIs, forms, and anywhere you want to enforce structure while still allowing flexibility.

Understanding :host-context() in Angular

Benjamin Arambide — Tue, 27 May 2025 14:54:39 +0000

Angular's default style encapsulation prevents styles from leaking into or out of components. But sometimes, you want your component to adapt based on context provided by external elements, such as a dark class on the <body> element. This is where :host-context() comes in.

What is `:host-context()`?

The :host-context() pseudo-class in Angular allows a component’s style to react to ancestor elements outside the component’s view encapsulation boundary.

It checks if the component is rendered inside an element matching the selector.

:host-context(body.dark) {
  .container {
    background-color: #222;
    color: white;
  }
}

This means: "Apply this style if the component is somewhere inside a <body class='dark'>."

When to Use It

Theming (e.g. light/dark mode)
Reacting to global classes or layout wrappers
Making components context-aware

Key Points

✅ :host-context() checks up the DOM tree, not down.
✅ It works with Angular's default ViewEncapsulation.Emulated.
❌ It does not work with ShadowDom encapsulation.
❌ Do not repeat the context selector inside the rule block.

Example

:host {
  .container {
    background: white;
    color: black;
  }
}

:host-context(body.dark) {
  .container {
    background: black;
    color: white;
  }
}

Common Mistake

// ❌ Incorrect
:host-context(body.dark) {
  .dark {
    background: black;
  }
}

This is wrong because .dark is already in the selector. You don't need to repeat it.

Summary

Use :host-context() to style Angular components based on their ancestors, such as when a global dark class is added to the <body> tag. It’s a powerful tool to make your components responsive to global layout or theming changes.

Understanding ViewContainerRef in Angular

Benjamin Arambide — Thu, 22 May 2025 01:58:55 +0000

When working with dynamic components in Angular, ViewContainerRef is an essential tool that allows you to programmatically manipulate the DOM and insert components at runtime. This article breaks down how to use @ViewChild with ViewContainerRef, and provides a practical example of rendering a component dynamically.

🔍 What is `@ViewChild`?

@ViewChild is a decorator that allows you to query a DOM element or Angular directive/component from your template.

Example:

@ViewChild('container', { read: ViewContainerRef, static: true })
container!: ViewContainerRef;

Breakdown:

'container': Refers to a template reference variable, like #container in the HTML.
read: ViewContainerRef: Tells Angular to return the ViewContainerRef instead of the default element/component.
static: true: Tells Angular to resolve this reference before ngOnInit() (eagerly).

🧱 What is `ViewContainerRef`?

ViewContainerRef represents a container where you can attach views dynamically. It's a class provided by Angular that gives you the ability to:

Create components at runtime
Insert, move, or remove embedded views
Interact with the component's change detection

📦 Dynamic Component Example

1. Host Component

@Component({
  selector: 'app-dynamic-host',
  template: '<ng-template #container></ng-template>',
})
export class DynamicHostComponent implements OnChanges {
  @Input() component!: Type<any>;
  @Input() inputs: Record<string, any> = {};

  @ViewChild('container', { read: ViewContainerRef, static: true })
  container!: ViewContainerRef;

  private componentRef!: ComponentRef<any>;

  ngOnChanges(): void {
    this.loadComponent();
  }

  private loadComponent() {
    this.container.clear();
    this.componentRef = this.container.createComponent(this.component);

    for (const [key, value] of Object.entries(this.inputs)) {
      this.componentRef.setInput?.(key, value);
      if (this.componentRef.instance.hasOwnProperty(key)) {
        this.componentRef.instance[key] = value;
      }
    }

    this.componentRef.changeDetectorRef.detectChanges();
  }
}

2. Dynamic Child Component

@Component({
  selector: 'app-my-dynamic',
  template: '<p>Dynamic component. Test = {{ test }}</p>',
})
export class MyDynamicComponent {
  @Input() test!: number;
}

3. Usage

<app-dynamic-host [component]="myComponent" [inputs]="{ test: 42 }"></app-dynamic-host>

💡 Summary

ViewContainerRef is crucial for rendering dynamic content in Angular.
You can use @ViewChild to get access to a container for inserting components.
This pattern is useful for modals, custom UI builders, dashboards, and plugins.

Dynamic components unlock the full power of Angular’s rendering engine, allowing you to build flexible and powerful interfaces.

Understanding TypeScript's `satisfies` vs `as`

Benjamin Arambide — Thu, 15 May 2025 05:42:12 +0000

In TypeScript, the satisfies operator is a safer, more precise alternative to as when you want to ensure a value conforms to a type without losing type inference.

Key Differences

Feature	`as`	`satisfies`
Type checking	Not enforced	Enforced
Keeps extra properties	No	Yes
Narrows `const` types	No	Yes
Safer for configuration objects	No	Yes

1. Keeping Extra Properties

Using `as` (unsafe):

type Person = {
  name: string;
  age: number;
};

const user = {
  name: 'Alice',
  age: 30,
  email: 'alice@example.com',
} as Person; // No error, but `email` is lost from the type

Using satisfies (safe):

const user = {
  name: 'Alice',
  age: 30,
  email: 'alice@example.com',
} satisfies Person;
// TS checks that name and age exist and retains `email` in the inferred type

2. Narrowing const Types

Using as:

const colors = ['red', 'green', 'blue'] as string[];

Using satisfies:

const colors = ['red', 'green', 'blue'] satisfies readonly ['red', 'green', 'blue'];

3. Ensuring Correct Object Shape

Using as (can lie):

type Config = { port: number };

const config = {
  port: '3000',
} as Config; // No error, even though it's wrong!

Using satisfies (type checked):

const config = {
  port: '3000',
} satisfies Config; // Type error: 'string' is not assignable to 'number'

4. With Utility Types

type Route = {
  path: string;
  name: string;
};

const routes = {
  home: { path: '/', name: 'Home' },
  about: { path: '/about', name: 'About' },
} satisfies Record<string, Route>;

Conclusion

Use satisfies when you want strong type validation without losing inferred details. It's ideal for configuration objects, constant arrays,

takeUntil - Operator for cleaning subscriptions

Benjamin Arambide — Mon, 12 May 2025 04:39:35 +0000

In RXJS, the takeUntil operator is an extremely powerful tool for automatic cleanup of subscriptions without the need to manually unsubscribe. It's a game-changer when it comes to preventing memory leaks and managing the lifecycle of subscriptions in Angular components.

🔧 How takeUntil Works

In Angular, managing subscriptions can get tricky, especially in large applications where multiple observables are subscribed to. Normally, you'd manually unsubscribe in ngOnDestroy to prevent memory leaks.

But instead of doing that, takeUntil allows you to automatically complete an observable when another observable emits, making your cleanup declarative and automatic.

✅ Example: Using takeUntil for Automatic Cleanup

import { Component, OnDestroy } from '@angular/core';
import { Subject, Observable } from 'rxjs';
import { takeUntil } from 'rxjs/operators';

@Component({
  selector: 'app-sample',
  template: `<p>Check your console for updates.</p>`
})
export class SampleComponent implements OnDestroy {
  private destroy$ = new Subject<void>();

  constructor() {
    // This observable emits every second.
    const observable$: Observable<number> = new Observable<number>((observer) => {
      let count = 0;
      setInterval(() => observer.next(count++), 1000);
    });

    // The subscription will automatically be unsubscribed when destroy$ emits.
    observable$.pipe(takeUntil(this.destroy$)).subscribe({
      next: (value) => console.log(value),
    });
  }

  ngOnDestroy() {
    // Emit to destroy the stream when the component is destroyed
    this.destroy$.next();
    this.destroy$.complete();
  }
}

🔍 What’s Happening?

takeUntil(this.destroy$): This tells the observable to complete when the destroy$ subject emits a value. The destroy$ subject is emitted in ngOnDestroy to complete the observable.
No need to manually unsubscribe. Once this.destroy$.next() is called, the subscription automatically ends, preventing memory leaks.
The magic happens because takeUntil listens to the completion signal from the destroy$ subject. Once that happens, your observable subscription is automatically unsubscribed.

🧠 Why takeUntil is a Hidden Gem:

Declarative Cleanup: You can declare when an observable should be completed rather than writing custom code to unsubscribe.
Memory Leak Prevention: Automatically unsubscribing when the component is destroyed or when a certain condition is met means no more manual memory leak handling.
Clean Code: It simplifies your component's lifecycle management by keeping the subscription logic close to the component's lifecycle hooks.
Great for Component Lifecycle: If you’re working with complex components or multiple async data streams, takeUntil helps you cleanly manage subscriptions without worrying about the timing.

🧩 Bonus: Using takeUntil with Multiple Observables

You can use takeUntil to manage multiple observables at once:

Improving Angular performance by limiting change detection checks for components

Benjamin Arambide — Mon, 12 May 2025 04:34:34 +0000

Angular offers a hidden gem: ChangeDetectionStrategy.OnPush. This strategy allows Angular to skip change detection for components unless specific conditions are met, drastically improving app performance. However, it’s underutilized, even though it can work wonders in dynamic UIs.

🔧 How Does ChangeDetectionStrategy.OnPush Work?

In Angular, the default change detection strategy (ChangeDetectionStrategy.Default) checks all components in the tree for changes — even if nothing has changed! This is fine for small apps, but for large apps, it kills performance.

With OnPush, Angular will only check a component if:

Input properties change.
Events (like clicks or user input) trigger updates.
Observable subscriptions change.

✅ Example:

@Component({
  selector: 'app-item',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `<p>{{ item.name }}</p>`
})
export class ItemComponent {
  @Input() item!: { name: string };
}

🔍 What’s Happening?

Angular will only check this component when one of the above triggers occurs, making it more performant.

This prevents Angular from checking components unnecessarily.

🧠 Why You Should Use It

Boosts Performance: It reduces the amount of work Angular has to do, especially in complex or large apps.
Improved Control: You can precisely control when Angular should check your component for changes.
Low CPU Usage: Great for reducing CPU cycles when you have lots of components or a dynamic UI.
Works Best with Immutable Data: If you're using an immutable data model (e.g., NgRx, Redux), Angular can detect changes quickly when references change.

🎯 How to Use It Effectively

To get the most out of OnPush, use immutable data structures. Angular relies on reference checks, so if the reference to an object doesn't change, it won’t trigger a re-render.

If you're doing manual data updates outside Angular's knowledge (like through setTimeout or WebSocket updates), use ChangeDetectorRef.detectChanges() to manually trigger change detection.

🧩 Bonus: Mix OnPush with Default

You can even combine both strategies in the same app to optimize performance:

@Component({
  selector: 'app-list',
  template: `
    <app-item *ngFor="let item of items" [item]="item"></app-item>
  `,
  changeDetection: ChangeDetectionStrategy.Default
})
export class ListComponent {
  items = [{ name: 'Apple' }, { name: 'Banana' }];
}

In this case, ListComponent uses the default change detection strategy, but each ItemComponent uses OnPush to optimize performance further.

📌 Summary

ChangeDetectionStrategy.OnPush is one of the best-kept secrets for improving Angular app performance.
It limits unnecessary checks, making your app faster and more efficient.
It works well when you use immutable data patterns and can be easily mixed with other strategies.

Use it to make your Angular apps blazing fast!

How can you use Angular's `ng-template` beyond basic ngIf or ngFor?

Benjamin Arambide — Mon, 12 May 2025 04:26:53 +0000

Yes! Angular's ng-template combined with *ngTemplateOutlet allows you to define and render dynamic templates — acting like content "portals" or reusable layout blocks.

🔧 Example: Dynamic Template Switching

<ng-template #loadingTemplate>
  <div class="spinner">Loading...</div>
</ng-template>

<ng-container *ngTemplateOutlet="isLoading ? loadingTemplate : mainContent"></ng-container>

<ng-template #mainContent>
  <p>The data is loaded!</p>
</ng-template>

🔍 What’s Happening?

You define named templates using #templateRef.
You dynamically insert a template using *ngTemplateOutlet.
This cleanly switches between content blocks without cluttering your HTML with logic.

🧠 Why It’s Useful

Keeps your templates clean and declarative.
Ideal for conditional UIs like modals, loading spinners, and card layouts.
Encourages reusable content logic, especially in component libraries.

🧩 Bonus: Passing Context

Templates can accept custom data too:

<ng-template #userCard let-user="user">
  <div>{{ user.name }}</div>
</ng-template>

<ng-container *ngTemplateOutlet="userCard; context: { user: currentUser }"></ng-container>

let-user="user" allows access to context inside the template.
You can build flexible, data-driven UIs this way.

📌 Summary

ng-template + *ngTemplateOutlet = Angular’s hidden power feature.
Enables reusable, dynamic content structures.
Cleaner alternative to nested *ngIf, ideal for advanced UI patterns.

Use it to build smarter, more modular Angular components!

How can you handle circular dependencies between Angular services without breaking the dependency injection system?

Benjamin Arambide — Mon, 12 May 2025 04:23:55 +0000

Angular provides a built-in function called forwardRef that allows you to resolve circular dependencies elegantly.

🔁 What is a Circular Dependency?

A circular dependency occurs when two classes depend on each other. For example:

ServiceA needs ServiceB
ServiceB also needs ServiceA

This creates a loop that Angular can't resolve at compile time.

🛠️ The Solution: forwardRef

You can use forwardRef to tell Angular: "Don't resolve this dependency now — wait until everything is defined."

✅ Example:

@Injectable()
export class ServiceA {
  constructor(@Inject(forwardRef(() => ServiceB)) private serviceB: ServiceB) {}
}

@Injectable()
export class ServiceB {
  constructor(private serviceA: ServiceA) {}
}

In this example:

We delay resolving ServiceB inside ServiceA until runtime.

This breaks the circular resolution problem.

🧠 Why It Works

Angular's DI system builds providers in a certain order.
If a token isn’t defined when it's injected, it fails.
But forwardRef(() => Type) defers the reference resolution to runtime — by then, Angular knows what ServiceB is.

🎯 When to Use

Use it when two services must reference each other, and you can’t redesign the architecture easily.

Use sparingly. If you use it often, it's a sign your services may be too tightly coupled.

📌 Summary

Circular dependencies break DI — but forwardRef solves this.

It allows lazy resolution of dependencies in services and components.

It's a powerful Angular feature that many devs overlook or misuse.

Destroy service for rxjs observables

Benjamin Arambide — Mon, 12 May 2025 04:17:32 +0000

🧩 Implementation:
Here an on destroy service for being used in rxjs and angular component for unsubscribing observables.

@Injectable()
export class DestroyService extends Subject<void> {
    ngOnDestroy() {
        this.next();
        this.complete();
    }
}

🧩 Question:
How Angular calls ngOnDestroy() in this pattern? Even though DestroyService is a service and extends Subject, how does Angular still invoke ngOnDestroy()?

💡 Answer:
Here's the key idea:

Even though DestroyService extends Subject (which is not a component or directive), Angular still calls its ngOnDestroy() method if the service is provided at the component level.

🔑 Why ngOnDestroy() Gets Called in a Service

✅ Angular will call ngOnDestroy() if:

The class implements OnDestroy
AND it is a provider on a component or directive

Example:

@Component({
  selector: 'app-foo',
  providers: [DestroyService]
})
export class FooComponent {
  constructor(private destroy$: DestroyService) {}
}

Then Angular treats the service like a directive-level provider, and because it has ngOnDestroy():
Angular will call that method when the component is destroyed.

🧠 Why It Works Even Though It Extends Subject

Subject has no ngOnDestroy(). That's fine.
You're extending Subject and adding ngOnDestroy() yourself.
Angular doesn’t care that it extends Subject — it just sees:
- “This class was provided in the component”
- “It has ngOnDestroy()”
- ✅ Call it when the component is destroyed

🔁 Summary

DestroyService is a service, but it's scoped to the component using providers: [DestroyService]
It has a custom ngOnDestroy() method
Angular calls ngOnDestroy() on component-scoped providers
So you get an automatic, injectable "destroy notifier" for use with takeUntil()

This is a neat Angular trick that combines:

Lifecycle hooks
Dependency injection
RxJS

into a reusable, composable unsubscribe mechanism.

Navigating ARM64 and x86_64 Architectures in macOS for Node.js Development

Benjamin Arambide — Sun, 22 Sep 2024 17:56:26 +0000

Navigating ARM64 and x86_64 Architectures in macOS for Node.js Development

As Apple transitions its hardware to ARM architecture with the introduction of M1 and M2 chips, developers face the necessity of supporting both ARM64 and x86_64 architectures. This article will guide you through switching between these architectures and explain why it's important for Node.js development.

Understanding the Architectures

ARM64

ARM64 (AArch64) is the architecture utilized by Apple Silicon chips. It offers significant performance and energy efficiency benefits, making it ideal for modern applications.

x86_64

x86_64 is the architecture used by Intel-based Macs. Many applications and libraries have traditionally been built for this architecture, leading to compatibility considerations.

Importance of Switching Architectures

Compatibility: Some Node.js packages, especially those with native components, may not be compiled for ARM64. Running these in x86_64 mode can prevent issues.
Performance Testing: Ensuring that applications perform well on both architectures is essential for a smooth user experience across different devices.
Development Flexibility: As the ecosystem shifts towards ARM64, developers often need to maintain support for x86_64 during this transition.

Switching Between Architectures

Running Terminal in x86_64 Mode

To open a new Zsh shell in x86_64 mode, use the following command:

arch -x86_64 /bin/zsh

Once inside this shell, any commands you run will operate in x86_64 mode.

Running Terminal in ARM64 Mode

To open a new Zsh shell in ARM64 mode, simply use:

arch -arm64 /bin/zsh

This command will launch a Zsh shell that runs natively on ARM64.

Running Node.js in Different Architectures

To execute a Node.js script in the desired architecture, use the same arch command.

For x86_64:

arch -x86_64 /usr/local/bin/node your-script.js

For ARM64:

arch -arm64 /usr/local/bin/node your-script.js

Make sure to replace /usr/local/bin/node with the path to your Node.js installation and your-script.js with the name of your script.

Summary

Switching between ARM64 and x86_64 architectures on macOS is essential for Node.js developers to ensure compatibility, optimize performance, and navigate the transition to Apple Silicon. By utilizing the arch\ command to run different shell sessions and Node.js scripts, you can maintain a flexible and efficient development environment.

If you have any further questions or need assistance with specific issues related to Node.js on macOS, feel free to reach out!

How to Launch Google Chrome Without CORS Protection on macOS

Benjamin Arambide — Fri, 20 Sep 2024 00:20:43 +0000

How to Launch Google Chrome Without CORS Protection on macOS

If you're a developer or testing applications that require disabling CORS (Cross-Origin Resource Sharing), you can easily launch Google Chrome without its CORS protections. This guide will show you how to create a simple command to do this on macOS.

Steps to Launch Chrome Without CORS Protection

1. Close Any Running Instances of Chrome

Before starting, ensure that all instances of Google Chrome are closed.

2. Open Terminal

You can find Terminal in Applications > Utilities > Terminal\.

3. Create a Shell Script

In the Terminal, create a new shell script by running:

nano ~/chrome-dev

4. Add the Launch Command

In the nano editor, add the following lines:

#!/bin/bash
open -na "Google Chrome" --args --disable-web-security --user-data-dir="/tmp/chrome_dev"

This script opens a new instance of Chrome with CORS disabled.

5. Save and Exit

Press CTRL + X\, then Y\, and hit Enter\ to save the file.

6. Make the Script Executable

Run the following command to make your script executable:

chmod +x ~/chrome-dev

7. Add to Your PATH (Optional)

To run the command from anywhere in the terminal, you can add it to your PATH.

Open your profile file:

For bash users:

  nano ~/.bash_profile

For zsh users:

  nano ~/.zshrc

Add the following line to the file:

export PATH="$HOME:$PATH"

Save and exit, then refresh your terminal:

For bash:

  source ~/.bash_profile

For zsh:

  source ~/.zshrc

Using the Command

You can now use the command chrome-dev\ in your terminal to launch Chrome without CORS protection.

Important Reminder

Disabling CORS makes your browser less secure. Use this mode strictly for development and testing purposes, and remember to return to normal browsing afterward.

Conclusion

This simple script can save you time when testing applications that require CORS to be disabled. Just remember to use it responsibly!

Simplify Observable Subscriptions in Angular with a Custom Destroyer Service

Benjamin Arambide — Sat, 29 Jun 2024 04:41:05 +0000

Simplify Observable Subscriptions in Angular with a Custom Destroyer Service

Managing observable subscriptions in Angular can be challenging, especially when it comes to ensuring that subscriptions are properly cleaned up to prevent memory leaks. One common approach is to use the takeUntil operator with a Subject that emits a value when the component is destroyed. This article will show you how to simplify this process by creating a custom Destroyer service that extends Subject.

Why Use `takeUntil`?

The takeUntil operator in RxJS allows you to automatically unsubscribe from an observable when another observable emits a value. This is particularly useful in Angular components where you want to unsubscribe from observables when the component is destroyed.

Creating the Destroyer Service

We will create a Destroyer class that extends Subject<void> and implements OnDestroy. This class will handle emitting a value and completing the subject when the component is destroyed.

Step 1: Create the Destroyer Class

First, create a service file called destroyer.service.ts and add the following code:

import { Injectable, OnDestroy } from '@angular/core';
import { Subject } from 'rxjs';

@Injectable({
  providedIn: 'root'
})
export class Destroyer extends Subject<void> implements OnDestroy {
  ngOnDestroy() {
    this.next();
    this.complete();
  }
}

In this class:

Destroyer extends Subject, which means it inherits all the functionality of a Subject.
It implements OnDestroy and overrides the ngOnDestroy method to call next() and complete(). This will emit a value and complete the subject when the component is destroyed.

Step 2: Use the Destroyer in a Component

Next, inject the Destroyer service into your component and use it with the takeUntil operator.

import { Component, OnInit, OnDestroy } from '@angular/core';
import { Observable, of } from 'rxjs';
import { takeUntil } from 'rxjs/operators';
import { Destroyer } from './destroyer.service';

@Component({
  selector: 'app-example',
  templateUrl: './example.component.html',
  styleUrls: ['./example.component.css'],
  providers: [Destroyer] // Ensure a unique instance per component
})
export class ExampleComponent implements OnInit, OnDestroy {
  data$: Observable<any>;

  constructor(private destroyer: Destroyer) {}

  ngOnInit() {
    this.data$ = of('example data').pipe(
      takeUntil(this.destroyer)
    );

    this.data$.subscribe(data => {
      console.log(data);
    });
  }

  ngOnDestroy() {
    // Destroyer will handle emitting destroy signal
  }
}

In this component:

The Destroyer service is injected through the constructor.
In ngOnInit, takeUntil is used with this.destroyer to manage the lifecycle of the observable.
When the component is destroyed, the ngOnDestroy method of the Destroyer service is called, which emits a value and completes the subject, unsubscribing from the observable stream.

Conclusion

Using a custom Destroyer service in Angular simplifies the process of managing observable subscriptions. By extending Subject and implementing OnDestroy, we can create a reusable service that handles the cleanup of observables automatically. This approach reduces boilerplate code and helps prevent memory leaks in your Angular applications.

Feel free to use and modify the code provided in this article to suit your specific needs. Happy coding!

DEV Community: Benjamin Arambide

Typing Objects with at Least One Property in TypeScript

Basic Use Case

Using Inline Types

Using Generics with Constraints

Dynamic Check with Type Predicate

Summary

Understanding :host-context() in Angular

What is :host-context()?

When to Use It

Key Points

Example

Common Mistake

Summary

Understanding ViewContainerRef in Angular

🔍 What is @ViewChild?

Example:

Breakdown:

🧱 What is ViewContainerRef?

📦 Dynamic Component Example

1. Host Component

2. Dynamic Child Component

3. Usage

💡 Summary

Understanding TypeScript's `satisfies` vs `as`

Key Differences

1. Keeping Extra Properties

Using as (unsafe):

Using satisfies (safe):

2. Narrowing const Types

Using as:

Using satisfies:

3. Ensuring Correct Object Shape

Using as (can lie):

Using satisfies (type checked):

4. With Utility Types

Conclusion

takeUntil - Operator for cleaning subscriptions

Improving Angular performance by limiting change detection checks for components

How can you use Angular's `ng-template` beyond basic *ngIf or *ngFor?

How can you handle circular dependencies between Angular services without breaking the dependency injection system?

Destroy service for rxjs observables

Navigating ARM64 and x86_64 Architectures in macOS for Node.js Development

Navigating ARM64 and x86_64 Architectures in macOS for Node.js Development

Understanding the Architectures

ARM64

x86_64

Importance of Switching Architectures

Switching Between Architectures

Running Terminal in x86_64 Mode

Running Terminal in ARM64 Mode

Running Node.js in Different Architectures

For x86_64:

For ARM64:

Summary

How to Launch Google Chrome Without CORS Protection on macOS

How to Launch Google Chrome Without CORS Protection on macOS

Steps to Launch Chrome Without CORS Protection

1. Close Any Running Instances of Chrome

2. Open Terminal

3. Create a Shell Script

4. Add the Launch Command

5. Save and Exit

6. Make the Script Executable

7. Add to Your PATH (Optional)

Using the Command

Important Reminder

Conclusion

Simplify Observable Subscriptions in Angular with a Custom Destroyer Service

Simplify Observable Subscriptions in Angular with a Custom Destroyer Service

Why Use takeUntil?

Creating the Destroyer Service

Step 1: Create the Destroyer Class

Step 2: Use the Destroyer in a Component

Conclusion

What is `:host-context()`?

🔍 What is `@ViewChild`?

🧱 What is `ViewContainerRef`?

Using `as` (unsafe):

How can you use Angular's `ng-template` beyond basic ngIf or ngFor?

Why Use `takeUntil`?