DEV Community: Henrique Custódia

Creating Custom RxJS Operators

Henrique Custódia — Sun, 26 Feb 2023 18:50:04 +0000

Since Angular has become a popular framework, RxJS is becoming increasingly popular. In this post I would like to write about a very nice feature in this fantastic library: custom operators!

A few months ago I have been trying to keep the chaining logic more readable in my RxJS code. It's very easy to write confusing code when we don't pay attention to how the operators are being composed.

In this post, I would like to show how to write an RxJS code using custom operators to keep the logic readable and easier to maintain over time.

How to create a custom operator? 🤔

It's very easy, really!

An RxJS operator is just a function that receives an observable as a parameter and returns a new observable.

For instance:

Generally, it's common to create factory operators (operators that return another function), because it'll become more intuitive for the developers to understand the operators' chain.

Here's an example of a factory operator:

Now, let's see some examples of how to use custom operators to create more readable code!

Creating an operator to filter odd numbers 🦄

It's simple to filter odd numbers, isn't it?

But creating a custom operator to name it'll become your code cleaner and more obvious. The readability will improve.

Let's see the code:

Creating an operator to search by text 🕵🏾‍♂️

Searching by text into an array might be easy, but generally doing it with RxJS turns the code a bit hard to understand over time.

But, before using a custom operator, let's see how the code would look when not using custom operators:

It's not impossible to understand the code logic, but it's difficult to get what it's doing when taking a quick look.

Because of that, naming the code logic is important.

That said, let's refactor the code above using custom operators:

toLowerCase and searchByText are operators that can be used to reuse the code, and it's much easier to understand what they're doing.

Conclusion 🥷

Using custom operators can help us to make the code more readable and easier to reuse across the projects.

It was a quick post about custom operators. That feature is helping me a lot to enforce the reusability in my Angular projects.

Thank you for reading! ✨

Angular 15: Using The Directive Composition API

Henrique Custódia — Wed, 02 Nov 2022 04:21:13 +0000

Angular v15 will be released pretty soon, and it's coming with a very nice feature called Directive Composition API.

But, what is it? 🤔

The Directive Composition API allows us to compose directives into components and other directives.

This API works only with standalone components (and standalone directives). As the 14 version added the standalone property, the 15 version added a hostDirectives property.

Let's see how to use this property.

The example below shows a directive called BoxDirective, that sets some styles to the AppComponent using the Composition API:

The result will be:

We can use this new API to reuse a lot of code. It's amazing.

Exposing the directive's input

When adding Inputs and Outputs to a directive, we need to expose those to the component to be able to use them. There are the input and output in the hostDirectives property because of it.

The following example adds an Input property to the BoxDirective.

And we'll add the color input to the inputs array to expose it to the component.

That way we can set a color to the BoxDirective

The result will be:

It's possible to rename the exposed input's name - generally useful when we have directives' inputs with the same name.

Using the renamed property:

Exposing the directive's output

To expose outputs as easily as with inputs. But there's a property called outputs specifically for it.

Using it

In the same way as inputs, it's possible to rename the output's name.

Bonus: OnDestroyDirective 💎

Let's create a reusable directive to destroy old subscriptions.

The following code creates a timer component that uses an interval operator to log an incremental number every second. To avoid memory leaks, it's a good practice to remove observable subscriptions when a component has been destroyed. The OnDestroyDirective will remove the interval subscription automatically after the timer component is destroyed.

The result will be:

👨‍💻

You can check out the code of this post here.

That's all!

I've spent some time writing this post, then, I hope that you enjoyed it!

If you liked it, give some claps/likes to this post or share it with your friends!

Thank you for the reading. 😄

See you! 👋🏼

Angular Inject Function: A New Way To Work With DI

Henrique Custódia — Thu, 13 Oct 2022 20:42:53 +0000

It's time to talk about one of the best features in Angular 14: inject function. I've been studying this new version for a while and I can say... Angular is getting better and better. Since the improvements in performance up to the developer's usability, it's becoming a great framework to work with.

I've written a post about standalone components, it's an amazing Angular 14 feature as well. Check out here!

But, well, let's talk about the inject function.

What is it?

It's a new feature released in Angular 14 that allows us to inject providers (services, tokens, components, etc.) without using the constructor class. It can be handy for those moments we aren't using a class - like when creating a factory provider for instance.

Also, we can use this function to avoid injecting providers using the well-known class constructor. It can be good for a more cleaned approach - avoiding several injects in the constructors which can be confusing along the time.

The following example shows how to inject a service and use it in the component:

It's very simple to use, indeed.

Inject dependencies into functions 👻

I think the better part about this inject function is the possibility to create "smart functions" that can inject services doing the code easier to understand.

Let's see an example of a function that injects the Renderer service and changes the CSS class of an HTML element.

Have you noticed?

The createClassManager and getHost are using the inject function. That's a good way to abstract the code into functions. Before, we had services to help us to break into pieces our code. But now, we can use functions that are a very natural way to work in Javascript.

Where can we use this function?

Based on angular documentation:

In practice the inject() calls are allowed in a constructor, a constructor parameter and a field initializer.

The inject function just works inside the injection context. We can call it when the instance is being created.

Injection Flags 🚩

Another nice thing about the inject function is the new way we can use the injection flags. Before, injecting the provider by constructor class, we had to use decorators like @host or @Optional to change an injection behavior. Now, with inject function, we just need to set some boolean flags using an options object as the second parameter.

it's much more simple, isn't it?

Using the injection by constructor class we'd have to use the way:

In my opinion, this new approach is much more simple to understand. Mainly, for those who are just starting to work with Angular.

Should we stop to use class constructors with DI?

Well, I don't think so.

Although the inject function is a great feature, it's just a new approach. We don't need to refactor the projects because of it. Probably class constructors and inject functions will be two options that'll coexist for a long time.

But, in my opinion, inject function brings a much more clean approach to work with DI. It's straightforward and avoids lots of parameters on the constructor.

👨‍💻

You can check out the code of this post on my GitHub.

That's all!

I've spent some time writing this post, then, I hope that you enjoyed it!

If you liked it, give some claps/likes to this post or support me in buying a coffee; it'll help me a lot! 👏🏼❤

Thank you for the reading. 😄

See you! 👋🏼

Angular Standalone Components: Say Goodbye To NgModules

Henrique Custódia — Sun, 25 Sep 2022 20:14:10 +0000

A few months ago, Angular v14 was released with a lot of amazing new features. And, since then, I've spent some time studying and applying these to my projects.

It's hard not to admit how excited I'm feeling about the standalone component feature. This feature, in my opinion, is the most relevant improvement that Angular has had over the years. That will change how we develop our applications, and, mainly, that will make the components simpler to read and write. In the future, we probably won't need NgModules anymore.

What's a standalone component?

Well, the standalone component is just a common Angular component that we already know but with further features. That is a combination of a component and a NgModule.

Therefore, we don't need to import our component into a NgModule to use it, because this kind of component is self-contained.

Let's see a simple code to understand how to use it.



@Component({
  selector: 'app-header',
  standalone: true,
  imports: [CommonModule],
  templateUrl: './header.component.html',
  styleUrls: ['./header.component.scss'],
  changeDetection: ChangeDetectionStrategy.OnPush
})
...

The code above has two new properties called standalone and imports.

But, what's it means?

standalone: It marks the component as a standalone component and enables all features related to it.
imports: It allows a component to import Directives, Pipes, Other Components, and existing NgModules.

Oh, can we import a component directly into another component?

Yes, we can! We don't need to create a NgModule just to register components anymore. With standalone components, we can import a component into another component, and Aha! it just works.

Let's see a quick example of it.



// Let's create header component
@Component({
  selector: 'app-header',
  standalone: true,
  template: `
    <p>header works!</p>
  `,
  ...
})
...



@Component({
  selector: 'app-layout',
  standalone: true,
  imports: [HeaderComponent],
  template: '<app-header></app-header>',
  ...
})

The result will be:

In another way using NgModule we'd have to create the following code:



@Component({
  selector: 'app-header',
  template: `
    <p>header works!</p>
  `,
  ...
})
...



@Component({
  selector: 'app-layout',
  template: '<app-header></app-header>',
  ...
})



@NgModule({
  declarations: [
    HeaderComponent, 
    LayoutComponent
  ]
})

It's much more verbose, isn't it?

The new approach with standalone components allows us to make Angular components simpler and more straightforward.

And, how to bootstrap an app using only standalone components?

With this new approach, we have a new function called bootstrapApplication.

This function allows Angular to bootstrap an application using a standalone component directly, no more a NgModule as we've known.



bootstrapApplication(AppComponent) 
    .then(() => { })
    .catch(() => { });

Generally, this code stands in main.ts file

With this approach, we need to change how we set the providers in the application as well. Let's see this in the next topic.

Setting providers to the application

Yep, a lot of things have changed! 😁

The bootstrapApplication function has a second parameter that allows us to add some configuration to the application.

Let's see the typescript declaration of it.



export declare interface ApplicationConfig {
    providers: Array<Provider | ImportedNgModuleProviders>;
}

As we can see, the providers property supports the Provider and ImportedNgModuleProviders.

Well, let's understand how to register a simple provider in the application - using the Provider type.



const ENABLE_DARK_THEME = new InjectionToken('ENABLE_DARK_THEME');

const providers: Array<Provider | ImportedNgModuleProviders> = [
    {
        provide: ENABLE_DARK_THEME,
        useValue: true
    }
];

bootstrapApplication(LayoutComponent, { providers })
    .then(() => { })
    .catch(() => { });

And to use the registered provider is the same way as we've already known.



export class LayoutComponent {
  constructor(
    @Inject(ENABLE_DARK_THEME) enableDarkTheme: boolean
  ) { }
}

Nothing that new so far, just the way we register the providers have changed.

What about routes, how can we register the app routes?

I was waiting for this question! It's changed as well. 😄

To register the app routes we have to use the new function calledimportProvidersFrom. Let's see what Angular documentation says about it.

Collects providers from all NgModules and standalone components, including transitively imported.

This function will extract all providers of the NgModule and set them to the provider's app array.

Let's see how to configure the app routes:



const ROUTES: Route[] = [
    {
        path: '',
        loadComponent: () => 
            import('./app/pages/home-page/home-page.component')
                .then(m => m.HomePageComponent)
    }
]

const providers: Array<Provider | ImportedNgModuleProviders> = [
    importProvidersFrom([
        RouterModule.forRoot(ROUTES)
    ])
];

bootstrapApplication(LayoutComponent, { providers })
    .then(() => { })
    .catch(() => { });



@Component({
  selector: 'app-layout',
  standalone: true,
  imports: [
    HeaderComponent,
    RouterModule
  ],
  template: `
    <app-header></app-header>
    <router-outlet></router-outlet> // Here comes the loaded component from the router.
  `,
  ...
})
export class LayoutComponent { }

It's become easier to configure the app router as we can load standalone components directly using the new loadComponent method. We don't need to create a lazy NgModule that uses the RouterModule.forChild anymore.

💭💭

I think the Angular v14 is just the beginning of something bigger and better! Angular has changed a lot over the last few years and it's exciting.

Standalone components allow us to create simpler applications in a faster way. This new feature also can make Angular an easier framework to learn, as we won't, in the future, need to use NgModule anymore - I hope so 😆.

For more information about standalone components and all their features, check out the official documentation.

👨‍💻

You can check out the code of this post on my GitHub.

That's all!

I've spent some time writing this post, then, I hope that you enjoyed it!

If you liked it, give it some claps/likes to this post; it'll help me a lot! 👏🏼❤

Thank you for the reading. 😄

See you! 👋🏼

Creating a Micro Frontend App with Angular Module Federation

Henrique Custódia — Tue, 30 Aug 2022 14:17:05 +0000

This post was inspired by Briebug's post

I've been listening much about the micro frontend concept lately. A lot of companies are adopting this solution as a way to make the apps smaller and easier to deploy.

But, what's micro frontend?

According to the micro-frontends website:

The idea behind Micro Frontends is to think about a website or web app as a composition of features which are owned by independent teams. Each team has a distinct area of business or mission it cares about and specialises in. A team is cross functional and develops its features end-to-end, from database to user interface.

That's cool! With a micro frontend, we can split an application into smaller pieces that focus on solving a specific problem. It's perfect for companies that need to work with dedicated squads at specific parts of the product, like a cart or checkout module, for instance.

This approach allows the squads to work with individual deploys and different stacks, without worrying about other projects that compose the entire solution.

What do we need to create a micro frontend app?

To compose a micro frontend app, we'll just need to have two kinds of applications:

Host

It's an application that will load the remote applications. We can have only one host app. This app can be called a shell as well.

Remote

It's an application that'll be loaded by the host application. We can have several of these apps. Generally, remote apps are small pieces of an application. Relevant modules that need some more attention and care.

Nice! And what do we're going to do?

In this post, we're going to do a micro frontend application using the amazing Angular Module Federation module and Nx to create and manage the project's workspace.

If you've never heard about Module Federation, check out this post .

Let's create the project then

On the terminal, just type the command below and generate an Angular application.



npx create-nx-workspace@latest

On the "application name" question, set the host as a name. That'll be the host application.

After that, you should have one app called host inside the project's workspace.

Now, let's create a new app called remote.



nx generate @nrwl/angular:application remote --port=5001

If everything worked fine, you'll have a new app inside the workspace.

All good?

Perfect! In the next steps, we're going to transform these two apps into an amazing micro frontend solution.

Setting the Angular Module Federation

It's time to add the Angular Module Federation to our project.

Let's type the following command on the terminal:



nx generate @nrwl/angular:setup-mf host --mf-type=host --routing

The following changes have been made inside the host app:

A file called module-federation. config has been created



module.exports = {
  name: 'host',
  remotes: ['remote'],
};

The bootstrap file contains the main's content file.
The main file loads the bootstrap file using an async import

The host app has become a shell app now - which means this app will be able to load remote apps.

Good, let's transform the remote app into a micro frontend app as well.

Run the following command on the terminal:



nx generate @nrwl/angular:setup-mf remote --mf-type=remote --host=host --routing

Now, just notice the remote app. Inside the app folder, we have now a new folder called remote-entry, and inside of it, there's an Angular module called RemoteEntryModule. This module will allow us to load the remote app inside the host app.

The entry.module.ts file should contain this content:



@NgModule({
  declarations: [RemoteEntryComponent],
  imports: [
    CommonModule,
    RouterModule.forChild([
      {
        path: '',
        component: RemoteEntryComponent,
      },
    ]),
  ],
  providers: [],
})
export class RemoteEntryModule {}

The RemoteEntryComponent will be the component that'll be loaded inside the host app.

Add some style to the remote component 🐉

I think that'd be good to make some changes to this component for it to look nice.

Don't worry! We'll just add a simple style to this.



@Component({
  selector: 'app-entry',
  template: `
    <div class="container">
      <span>I'm a remote app :)</span>
    </div>
  `,
  styles: [
    `
      .container {
        border: 1px solid green;
        padding: 24px;
      }
    `
  ]
})
export class RemoteEntryComponent {}

Cool!

Let's add a route to load de remote app

Now, inside the host app, let's add a route to load the remote app.

Add a file called app-routing.module.ts inside the app folder, with the following content:



const routes: Routes = [
    {
        path: 'remote-app',
        loadChildren: () => import('remote/Module').then(m => m.RemoteEntryModule)
    }
]

@NgModule({
    imports: [RouterModule.forRoot(routes)],
    exports: [RouterModule]
})
export class AppRoutingModule { }

Have you noticed? The route remote-app will load the remote/Module path. It's a file that webpack will create using the configuration file module-federation.config inside remote app.

Oh! We can't forget to import the routing module into the AppModule.



@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule, 
    AppRoutingModule // here
  ],
  providers: [],
  bootstrap: [AppComponent],
})
export class AppModule {}

Almost there!

To finish the app, let's change de AppComponent's template to something better



<div class="container">
    <div>I'm the host app</div>

    <a [routerLink]="['/remote-app']">load the remote app</a>

    <router-outlet></router-outlet> // the remote app comes here
</div>



.container {
    border: 1px solid red;
    padding: 24px;
}

Time to see the result

Well, now it's time to see the micro frontend application running. 😎

Run the command below on the terminal:



nx run-many --target=serve --all

Accessing the host app we'll see the following page:

When we click on the load the remote app link, the host app will load the remote app using the /remote-app route

We made a micro frontend app! That's awesome how easy it was, isn't it?

Curious about the code?

You can find the source code of this app on my Github.

If you're curious to see the app running, I've deployed this to production. Check out the app here!

That's all

I've spent some time writing this post, then, I hope that you've enjoyed it!

Don't hesitate to share this post with your friends - I know that content can be helpful for lots of people.

Thank you for the reading. 😄

Bye! 👋🏼