DEV Community: Preston Lamb

Git Worktrees In Use

Preston Lamb — Fri, 09 Dec 2022 00:00:00 +0000

tldr;

Most of us use Git every day, but generally use only the features that we are familiar with and allow us to do our job. There's nothing wrong with this at all, but learning new tricks can take your productivity up a level! With that in mind, let me introduce you to Git Worktrees.

Git Worktrees allow you to pull a git repository to your computer and then work on multiple branches at a time if desired. A standard git clone command pulls the repository to your machine and starts you working on a particular branch. If you need to switch branches, you have to either commit and push your code or stash the changes. When you clone the repo with the intent to use worktrees, you don't check out a particular branch initially. Let's learn how to use Git Worktrees!

Cloning Your Repo

Let's start by cloning the repository to your machine.

$ git clone --bare git@github.com:pjlamb12/worktree-demo.git worktree-demo

The above command looks similar to your normal git clone, with one important extra piece: --bare. This flag is what clones the repo to your machine without checking out a particular branch. You can read more about the flag here. The last part of the command, worktree-demo, names the folder that the repository will be cloned into. Normally git clone will clone the repo into a folder that's named the same as the repository URL, minus the .git. git clone --bare will keep the .git extension on the folder when cloning. If you don't want the .git on the folder name, provide the name of the folder as I've done above.

At this point, you have the repository cloned to your machine. If you change into the directory and list the contents, you'll see a few files like HEAD, config, and description, along with a couple folders like hooks, info, and objects. This is just an example; yours may not be exactly the same.

If you run the git status command, you'll see an error that says something along the lines of, "this operation must be run in a work tree". This lets you know that you can't do any work on your repository in this main folder. Let's look next at how to create a worktree so you can make some changes to your app.

Adding a Worktree

Let's add our first worktree, which we'll call main and will be based off the HEAD of the repo. You can add that worktree like this:

$ git worktree add main

If you list the contents of the directory, you'll now see a new folder called main. If you change into that directory and list the contents you'll see your application code. Also, git status will now give you the status that you expect to see. You'll no longer see the error mentioned above.

You can now always view the code in your repository at the main branch. To update the worktree, run the git pull command. This will get all the latest commits to the branch and update your worktree. I recommend not doing any work on your application in this worktree, however. This worktree is useful to have on your computer and ready to go so that you can troubleshoot any issues that teammates may be having, for example. If you want to make a change to the application, create a new worktree just like you would create a new branch.

Adding a Worktree with a New Branch

The command to create a new worktree and a new branch is similar to the add command above, but with an extra flag.

$ git worktree add -b my-new-branch worktree-name

The flag you need to provide is the -b branch-name flag. Whatever you use as the value for this flag will be the name of the branch when you push it to the repository. The last argument, worktree-name, is the name of the worktree on your computer and will be the name of the folder where the code is stored. This command does the same thing as the first add command, but a new branch is created with the given name.

Now that you have a worktree and branch created to make your changes, you can work on your application the same as you always do. Make changes, commit them, push them, and then merge the pull request. The first time you push the code, remember to use the --set-upstream flag:

$ git push --set-upstream origin my-new-branch

After you've used this flag the first time, git push will suffice.

Add a Worktree Based on a Remote Branch

The above commands are helpful but don't cover all situations. Sometimes you need to help your coworker with an issue they are seeing on their branch. This is where you can really see the benefits of worktrees. You can leave the worktree that you're working on untouched on your machine, and add a new worktree based on your coworker's branch. You can add this new worktree like this:

$ git worktree add worktree-name branch-name

Again, this is similar to the first add command but the branch-name argument will start you off on a branch in the repository instead of from the HEAD commit. You'll be able to change into the worktree folder and browse the code as your coworker is seeing it, but you won't have been required to commit your unfinished code to switch branches.

Updating a Worktree

Often when you're working on a feature branch the main branch has someone else's code merged to it. At that point you'll need to update your feature branch with rebase or merge. These same methods of updating your worktree can be used. You can update your worktree by rebasing or merging. You can decide the which method you would like to use. This article explains the differences between rebase and merge.

Before merging or rebasing, make sure that your local main worktree has been updated with git pull. After your local worktree is updated, you can merge or rebase your feature branch.

Removing a Worktree

After you finish up with a worktree, you'll want to remove the worktree from your machine. Each worktree will take up space on your hard drive, so you'll eventually run out room if you don't remove unused workspaces. You can remove them with the remove command:

$ git worktree remove worktree-name

The worktree and all related files will be removed from your computer.

Listing Worktrees

If you need to list the worktrees you've created, you can use the list command:

$ git worktree list

This will list all the local worktrees you've created on your machine.

Conclusion

When I found out about worktrees, I could see the potential benefits immediately. The ability to have multiple branches checked out on your computer at a single time is really powerful, especially when working with a team. Gone are the days of committing completely unfinished code to your feature branch so you can switch branches to help a coworker. It's not necessarily a "one size fits all" solution, but I'm excited about the possibilities. Hopefully this article helps you get started

Nx Conf 2022 Recap

Preston Lamb — Wed, 09 Nov 2022 00:00:00 +0000

tldr;

Nx Conf 2022 is in the books, and it was great. The in person group was small, but not too small. It was a great size for being able to interact with fellow attendees, speakers, and Nrwl team members. The speakers were well prepared with practical examples of how to best use Nx to improve the maintainability and architecture of your applications. Here’s a brief overview of some of my favorite talks. But I mean it when I say that just because I don’t mention a talk doesn’t mean it wasn’t good; these are simply talks that will benefit me and the projects I work on in the next few weeks. The presentations will be released soon, and when they are you should go watch them!

Generators

Many people talked about the importance of using generators, custom or community, to improve the quality of your application. Automating tasks that otherwise need to be done manually means you as a developer can be more efficient, but it also limits the number of times people can accidentally mess something up.

My favorite talk on the subject was by Lara Newsom. She gave a very practical use case for why you would use custom generators, and walked through how to create one. In 25 minutes I went from being overwhelmed by creating a generator to being ready to build one on my own. (Coincidentally, this was one of Lara’s goals for her talk. She succeeded 😉).

In Lara’s example, she showed how to compose other generators, in this case the Angular library creation generator, to limit the number of inputs available to only ones that your project actually cares about. This allows for consistency when creating the libraries, and prevents other developers from being overwhelmed about creating the libraries needed for your app. This is something that I plan on implementing for our workspace as soon as possible. I plan to do the same for creating apps and components so that everything is created with consistency and with the correct files.

Component Testing

I think we can all agree that testing is not always the highest task on our list. But it is a vital part of having a stable application. Cypress has definitely changed the way I think about writing tests. The developer experience is so smooth, and it just feels good to write tests.

The newest Cypress feature for Angular is component testing. The ability to isolate a component and test its actual display and interactivity is really appealing. The component is mounted and run in an actual browser, and can be tested to ensure it behaves and looks as it is supposed to. This is another tool in the testing tool belt, and one that I plan to spend some more time looking into.

The Cypress and Nx teams have made it easy to get things set up in your app for component testing. This is yet another example of a great development experience: the migrations are essentially handled for you, and you just reap the benefits.

CI

Multiple people also spoke about the benefit of using Nx Cloud, and the amount of time that is saved by running tests, builds, or linting while using Nx Cloud is mind-boggling. If you have things set up correctly on your CI, the amount of time your CI run takes to complete can be significantly faster than otherwise. The time is saved by caching the output of certain actions and replaying it if the affected code hasn’t changed. Thus you don’t need to continue to re-test or re-build your code. It was said that one client saves 40,000 hours a month in their CI time by using Nx Cloud. That’s likely on a fairly large app, but even smaller apps can save hours over the course of a month all of which is time back in your life and money back in your pocket.

If you need to get started with getting your CI set up properly, Nx provides a generator to add different CI workflows for you. It’s straight forward and worth the time investment up front. (Quick story: I found a bug in the generated GitHub Action, and within a couple hours of creating an issue the issue was resolved. You can’t ask for a better response time than that.) After getting the CI file from the generator, you can be up and running pretty quickly and start reaping the benefits of Nx Cloud.

General Conference Experience

I’ve been to several rounds of ng-conf and it’s always a great time, but the size of it can make you feel lost and it’s pretty easy to blend in. That was not the case at Nx Conf this year. I don’t know the final numbers, but I’d guess there were about 100 people in person, maybe slightly more, but it was a great size. It was easier to find people to talk to, and to really make connections with people. I’ve interacted with many on the Nrwl team on Twitter over the last few years, but hadn’t met many of them in person. But because of the size of the conference it was so much easier to approach them and talk to the, both during the conference and at the after party.

The Nrwl team, and ZeroSlope Events, did such a great job with everything about the conference. The hotel was great, the amenities were great, the location was great. I will definitely be shooting to make it back to the next Nx Conf

RxJS: defaultIfEmpty

Preston Lamb — Wed, 28 Sep 2022 00:00:00 +0000

RxJS: defaultIfEmpty

tldr;

RxJS pipelines are convenient ways to get work done in your applications. You can essentially tell the app the steps it needs to take, and it will go step by step through the pipeline. But what if one of the steps will potentially be empty, but you want the pipeline to continue? That’s where the defaultIfEmpty operator can come in handy. I recently learned about it when I had a similar situation, and it worked perfectly for me.

Background

I was recently working on an application where you needed to be able to add, edit, and delete data. The work needed to be done in a certain order: deletions first, then additions or edits. This is straightforward as long as there are actions for each of the above types to be done: at least one add, one edit, and one delete. But what happens if one of those types doesn’t need to be done in a given pipeline?

This is the situation I found myself in. If the delete observable was empty, nothing happened. I needed the pipeline to continue, however, and move on to adds and edits. I started searching around and found the defaultIfEmpty operator, which solved my problem for me.

`defaultIfEmpty`

The defaultIfEmpty operator does exactly what it sounds like: it provides a default value in the pipeline if the preceding observable doesn’t emit a value. This ensures that the pipeline doesn’t get stuck, but instead outputs a value.

Let’s look at a couple examples. First we’ll look at an example pipeline where there is a type for adds, edits, and deletes.

const deletions = [of('delete 1')];
const additions = [of('add 1')];
const edits = [of('edit 1')];

zip(...deletions)
  .pipe(
    tap((deletionResult) => console.log(deletionResult)),
    switchMap(() => zip(...additions)),
    tap((additionResult) => console.log(additionResult)),
    switchMap(() => zip(...edits)),
    tap((editsResult) => console.log(editsResult))
  )
  .subscribe();

In the above example, this pipeline will execute as expected. The deletion observables will run and emit a value, then the additions, then the edits. The result of all three sections will be logged to the console. Easy enough, right? But what do we do if we have no deletions to run?

const deletions2 = [];
const additions2 = [of('add 2')];
const edits2 = [of('edit 2')];

zip(...deletions2)
  .pipe(
    tap((deletionResult) => console.log(deletionResult)),
    switchMap(() => zip(...additions2)),
    tap((additionResult) => console.log(additionResult)),
    switchMap(() => zip(...edits2)),
    tap((editsResult) => console.log(editsResult))
  )
  .subscribe();

In this example, nothing gets logged to the console. We never move past the first step, because nothing is ever emitted from the initial zip(...deletions2) portion of the pipeline. But just because we don’t have anything to delete doesn’t mean we don’t want to continue with adding and editing the other pieces. This is where the defaultIfEmpty operator comes in handy. Insert it after a given step in the observable pipeline that could potentially emit no data. Then the pipeline will continue. Continuing with the above example, we can change it to the following to get our pipeline working again.

zip(...deletions2)
  .pipe(
    defaultIfEmpty([]),
    tap((deletionResult) => console.log(deletionResult)),
    switchMap(() => zip(...additions2)),
    tap((additionResult) => console.log(additionResult)),
    switchMap(() => zip(...edits2)),
    tap((editsResult) => console.log(editsResult))
  )
  .subscribe();

Now our pipeline continues and values are logged to the console. The defaultIfEmpty([]) operator essentially says if the preceding observable doesn’t emit a value, emit an empty array and then continue on to the next step. So, although we don’t have anything to delete, we can still do our adds and edits.

Let’s look at one last example, where we have deletions and edits to do, but no additions. Can you guess what will happen?

const deletions3 = [of('delete3')];
const additions3 = [];
const edits3 = [of('edit 3')];

zip(...deletions3)
  .pipe(
    tap((deletionResult) => console.log(deletionResult)),
    switchMap(() => zip(...additions3)),
    tap((additionResult) => console.log(additionResult)),
    switchMap(() => zip(...edits3)),
    tap((editsResult) => console.log(editsResult))
  )
  .subscribe();

If you guessed nothing happens at all, you’re close. But it does finish the delete step before stopping. So your edits never occur. To fix the issue, we just need to add another defaultIfEmpty operator.

zip(...deletions3)
  .pipe(
    tap((deletionResult) => console.log(deletionResult)),
    switchMap(() => zip(...additions3).pipe(defaultIfEmpty([]))),
    tap((additionResult) => console.log(additionResult)),
    switchMap(() => zip(...edits3)),
    tap((editsResult) => console.log(editsResult))
  )
  .subscribe();

Note: You can add the defaultIfEmpty operator in the pipe for the additions like I have above, or you can add it directly after the switchMap; either way will work.

With this minor change to our pipeline, it now finishes as we expect. The deletions are made, followed by the edits.

Conclusion

I was initially stuck with figuring out how to make sure my pipeline continued, even if there was an empty step in the pipeline. But I should have known there was an operator to help me out. There are a lot of operators, and while it makes RxJS seem overwhelming at first it’s also very convenient for situations like this. When you get stuck, ask for help and read the docs. You’re likely to find someone who’s run into the same problem and can point you in the right direction.

Here’s a StackBlitz with the examples we looked at above

Astro + Angular

Preston Lamb — Thu, 15 Sep 2022 00:00:00 +0000

tldr;

Astro is a relatively new, all-in-one framework with the goal of creating performant, content-focused websites. The great part is that while there is some new Astro specific syntax you can learn, you can also bring your own frontend. Until recently, Angular was the exception to that rule. But with the release of standalone components to the Angular framework, you can now pair Astro and Angular together.

Background

We won’t go fully into what Astro is in this blog post, but we’ll at least get into the basics. On June 8th, 2021, a blog post was released by the Astro team explaining that their goal was to provide a web framework that shipped less JavaScript to the browser. It is described as similar to a static site generator, similar to Jekyll or Eleventy. After the build step, most JavaScript is removed from the page, and all that’s left is the HTML. In the case that JavaScript is needed for some functionality, Astro loads only the necessary JavaScript. The result are sites that are as lightweight and fast as possible. In the time since that blog post was released, a lot of content has been produced. If you’re interested in Astro, you should definitely go read more about it.

To get started with Astro, you only need to run the following command:

npm init astro

A few prompts will be displayed; follow them through to the end and you should have your basic project ready to go. Once the project is completed, you’re ready to go on to the next steps.

Implement Angular and Astro

As mentioned in the intro, Astro allows you to bring your own frontend to build your site. React, Vue, and Svelte have been supported since the beginning. Angular was not available until v14.2, when standalone components were introduced. With that addition to the framework, you can now pair Angular and Astro.

Another thing to be aware of, however, is that Angular’s standalone components don’t work 100% with Astro. For example, inputs to components work but outputs don’t. You’ll need to be aware of this when developing your application.

Now that you have an Astro application, let’s get it working with Angular. You can do that with a single command from your terminal.

npx astro add @analogjs/astro-angular

This command makes changes to the astro.config.mjs file, and installs some Angular dependencies for you to develop your site. There’s one more step needed after this, and that is to create a tsconfig.app.json file. You can find an example here. Add that file into the root of your project.

Let’s continue by creating a component in the src/components folder. Let’s call ours header.component.ts, like for a blog post header. That file, at its very basic configuration, will look like this:

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

@Component({
  selector: 'app-header',
  standalone: true,
  template: `<div>
    <h1>{{ title }}</h1>
    <p>New Blog Post</p>
  </div>`,
})
export class HeaderComponent {
  @Input() title: string;
}

Now that we have our component, let’s add it to our Astro template, in the src/pages/index.astro file. This will be different from what you’re used to with Angular components. You’ll first need to import the component at the top of the file, inside the pair of triple dashes:

---
import { HeaderComponent } from '../components/header.component';
---

After that, next to some of the other HTML in the astro file, add your new Angular component:

<HeaderComponent title="Angular + Astro" />

If you’ve used React, this will look more familiar. Also, make sure to provide a title as an input.

After adding the component to your page, run the following command and open the site on the provided port:

npm run dev

When you open the page, you should see the content of your new component on the page, wherever it is that you added it.

Conclusion

There is a lot of innovation happening in the Angular community recently, and because of it we are able to move forward and take advantage of new tools that the web development industry has to offer. Astro is beginning to grow, and as Angular developers we can now jump in and participate. I encourage you to go read this article by Brandon Roberts for more information on using Astro and Angular. You can also follow Brandon’s project, Analog, to see more innovation in the Angular community

Reusable Component Pieces with ngTemplate Outlet

Preston Lamb — Mon, 25 Jul 2022 00:00:00 +0000

tldr;

ng-template, ng-container, and ngTemplateOutlet provide the ability to reuse content inside an Angular component. Understanding what’s going on and how to use these methods allows a developer to build what they want without needing to duplicate parts of the template.

Explanation of the Problem

Have you ever needed to use *ngIf in your template, and if the expression evaluates to false use a backup template? On top of that, maybe both situations (if the expression is true or false) require the same layout inside of the element that has the *ngIf directive on it.

I recently had came across this situation. We had some data that was being output in a list either had a link that stayed internal to the app or opened a link in a new tab external to the application. The content inside the links, however, always had the same layout. I didn’t want to duplicate the inner content, and luckily Angular provides the ability to accomplish this. The method includes using ng-template, ng-container, and ngTemplateOutlet.

Before getting to the end solution, let’s look at an example of the data and how it’s output without using ng-template.

export class ListComponent {
  links = [
    { internal: true, display: "Home", url: "/" },
    { internal: false, display: "External", url: "https://test.com" },
  ];
}

<ul>
  <li *ngFor="let link of links">
    <a *ngIf="link.internal" [routerLink]="link.url">
      <img src="/assets/icon.svg" alt="">
      <span>{{ link.display }}</span>
    </a>
    <a *ngIf="!link.internal" [attr.href]="link.url">
      <img src="/assets/icon.svg" alt="">
      <span>{{ link.display }}</span>
    </a>
  </li>
</ul>

In this method, we have two *ngIf directives on two separate a tags, and the inner content of the link is the same in both cases. If that inner content changes, we have to make the change to both places or else there are inconsistencies in the layout. This is not ideal; we are repeating ourselves and there are multiple locations where we can introduce bugs.

Solution

Angular provides a much more elegant solution to our problem. Our TypeScript code from above will remain the same, but we can have a lot less duplication in the HTML by using a couple special Angular tags. First I’ll show the HTML, and then we’ll discuss the different pieces.

<ul>
  <li *ngFor="let link of links">
    <a *ngIf="link.internal; else externalLink" [routerLink]="link.url">
      <ng-container
        [ngTemplateOutlet]="linkLayout"
        [ngTemplateOutletContext]="{ link: link }"
      ></ng-container>
    </a>
    <ng-template #externalLink>
      <a [attr.href]="link.url">
        <ng-container
          [ngTemplateOutlet]="linkLayout"
          [ngTemplateOutletContext]="{ link: link }"
        ></ng-container>
      </a>
    </ng-template>
  </li>
</ul>

<ng-template #linkLayout let-link="link">
  <img src="/assets/icon.svg" alt="" />
  <span>{{ link.display }}</span>
</ng-template>

There’s a lot going on here, so let’s break it down. We’ll start with the *ngIf on the a tag.

<a *ngIf="link.internal; else externalLink" [routerLink]="link.url">
  <ng-container
    [ngTemplateOutlet]="linkLayout"
    [ngTemplateOutletContext]="{ link: link }"
  ></ng-container>
</a>
<ng-template #externalLink>
  <a [attr.href]="link.url">
    <ng-container
      [ngTemplateOutlet]="linkLayout"
      [ngTemplateOutletContext]="{ link: link }"
    ></ng-container>
  </a>
</ng-template>

The *ngIf directive has an expression listed: if link.internal evaluates to true, then show this a tag. If it’s false, output the ng-template tag that’s referenced by the externalLink local template variable. This is how we can either navigate to a new route that’s part of the Angular app or external to the app. This is a method that can be used in any situation where your *ngIf needs an else clause.

Next up, let’s look at what’s going on with the ng-container inside both of the a tags in the example.

<ng-container
  [ngTemplateOutlet]="linkLayout"
  [ngTemplateOutletContext]="{ link: link }"
></ng-container>

You can read more about the ng-container element in the Angular docs, but at a high level it’s a special element that can hold structural directives without adding new elements to the DOM. It can also be used in situations like this, with the ngTemplateOutlet structural directive. The ngTemplateOutlet directive determines what ng-template will be output on the page inside the ng-container. The context for the template, or needed variables, can be declared with the ngTemplateOutletContext directive. In the above case, we are saying that the #linkLayout content should be output on the page, and that there should be a variable called link that will be used inside the ng-template. The contents of the ng-template tag can be placed anywhere in the HTML file, though I’ve placed them at the bottom in this example.

<ng-template #linkLayout let-link="link">
  <img src="/assets/icon.svg" alt="" />
  <span>{{ link.display }}</span>
</ng-template>

This template will be output on the screen anywhere it’s referenced. In this case, inside both a tags. If we want to change the layout inside the a tags, we need only change this one spot in the HTML. Everything will be kept in sync, and we have fewer possibilities of inconsistencies in the component.

There is one alternate way of declaring the ngTemplateOutlet. The result will be the same as the method shown above.

<ng-container
  *ngTemplateOutlet="linkLayout; context: { link: link }"
></ng-container>

Conclusion

The above method limits the duplication to a certain degree, especially for the content inside the a tag. The example here is a fairly simple layout. This method becomes more useful when the internal layout becomes more complicated. That inner layout is defined once and reused in multiple locations. You could create a new component if you wanted, but that can introduce complexity sometimes as well.

Knowing how to use ng-template, ng-container, and ngTemplateOutlet can allow you to effectively output the content of a component with minimal duplication

Angular Lifecycle Hooks

Preston Lamb — Fri, 22 Jul 2022 00:00:00 +0000

tldr;

Each Angular component has a lifecycle that lasts from the time the component is added to the page until it is removed from the page. There are several times to hook into the lifecycle, where you can run some code necessary for the component. We’ll look at a few of the most common hooks.

Angular Lifecycle Hooks

Angular has several lifecycle hooks, which you can view in detail on the docs. Here’s the list of hooks:

ngOnChanges
ngOnInit
ngDoCheck
ngAfterContentInit
ngAfterContentChecked
ngAfterViewInit
ngAfterViewChecked
ngOnDestroy

Each of the above lifecycle hooks run at various times during the lifecycle of the component. Depending on your needs you can run code when those events occur. Some are more useful and more commonly used than others. Let’s look at some examples of the hooks which I believe are most useful.

`ngOnInit`

Let’s start with what is likely the most common lifecycle hook, ngOnInit. This hook is used to initialize certain information or data used in the component. It’s run once, after ngOnChanges is run. If you’ve worked in an Angular component at all, you’ve likely seen and used ngOnInit.

There is one main “gotcha” to remember with this lifecycle hook. If the component’s data is changed, but it remains on the screen, ngOnInit does not run again. This includes when a component is used for a route in your app. Let’s say we have a DetailComponent that shows the detail of a user. The userId is pulled from the route params and the data is shown on the page. If you route to the detail of a new user, the data will need to change but ngOnInit will not be run again, even though the route changes.

Here’s a brief example of an ngOnInit method:

ngOnInit() {
  this.results = this._dataService.getResults();
}

`ngOnChanges`

The next hook we’ll look at is ngOnChanges. This hook is used to respond to changes to the data that’s passed in to a component. It is run any time the data-bound properties of the component change. The first time it's run is before ngOnInit is run.

A good use case for ngOnChanges is when a component has some data passed in, and subsequent calculations need to be made with that data to display in the component. If you were to make the calculations in the ngOnInit hook, the data would not update as you expect or desire when the inputs are changed. This is due to ngOnInit only being run once.

Here’s an example of what may happen in the ngOnChanges method:

ngOnChanges(changes: SimpleChanges) {
  this.total = this.inputOne + this.inputTwo;
}

The ngOnChanges hook takes an optional argument of type SimpleChanges. Each attribute on the SimpleChanges object has three attributes: currentValue, previousValue, and firstChange. Those three attributes are included on an interface called SimpleChange. These attributes are pretty self explanatory, and allow you to react however you need to in your components. The only attributes present on the SimpleChanges object are ones that changed in that particular run. So, if inputOne changes, but not inputTwo, then the object would look like this:

{
  "inputOne": {
    "previousValue": 1,
    "currentValue": 2,
    "firstChange": false
  }
}

If the data in your component should be re-calculated when the inputs change, use the ngOnChanges hook.

`ngAfterViewInit`

The AfterViewInit hook allows you to respond when the component’s view and child views are visible on the screen. This hook runs just once, after the first time ngAfterContentChecked is run.

The ngAfterViewInit hook is perfect when you need to reference an element of the component’s template inside the TypeScript class. If you try and reference the element in the ngOnInit hook, there is a good chance that the variable will still be undefined. Waiting until the ngAfterViewInit hook runs ensures that the element will be in the screen, provided it’s not been removed from the screen with the *ngIf directive.

Here’s an example of using the ngAfterViewInit hook:

export class DemoComponent implements AfterViewInit {
  @ViewChild('myElement') myElement: ElementRef;

  ngOnInit() {
    console.log(this.myElement); // undefined
  }

  ngAfterViewInit() {
    console.log(this.myElement); // ElementRef { ... }
  }
}

`ngOnDestroy`

The ngOnDestroy hook is run when Angular removes the component from the application. It can be used for cleanup of the component, including unsubscribing from long-lived observables or removing event handlers.

It’s important to remember that Angular needs to remove the component from the app for the hook to run. If you refresh or close the browser tab, the component is technically removed from the browser, but Angular didn’t control the removal of the component. Thus, the ngOnDestroy hook is not run.

Here’s an example of using the ngOnDestroy hook:

private subscription;

ngOnInit() {
  this.subscription = this.someService.appState.pipe().subscribe();
}

ngOnDestroy() {
  this.subscription.unsubscribe();
}

Best practice is to subscribe to observables using the async pipe. If you do that, there’s no need to clean up subscriptions in the ngOnDestroy hook. However, some situations require you to subscribe to the observable in the TypeScript file and this will allow you to unsubscribe from the Observable and prevent memory leaks in your app.

Conclusion

In my experience, these are the most used lifecycle hooks. Understanding how they are used and in what situations will allow you to be most effective when writing your Angular apps. The other hooks I mentioned at the beginning of the article can also be helpful, but aren’t as common as the four covered here

Angular Typed Reactive Forms

Preston Lamb — Wed, 20 Jul 2022 00:00:00 +0000

tldr;

Reactive forms in Angular are a convenient way to manage your forms and react to changes made by the user. One issue with them has been that the value of the form has not been typed. Because of this, you could improperly access a value from a form and not know until runtime. Angular v14 introduces typed reactive forms, and removes this potential issue.

The Issue

Let’s look at a sample reactive form declaration:

this.form = new FormGroup({
  name: new FormControl(''),
  email: new FormControl('')
});

This form has two controls, name and email. With untyped reactive forms, I could write the following (valid) code, which would cause an error at runtime:

const firstName = this.form.value.name.firstName;

The name value on the form is just a string, not an object, so I shouldn’t be able to access .firstName. The reason I can in this example is because at some point in the API for reactive forms, any was used in the type.

Strongly typed reactive forms will change this behavior, however, and ensure that you only access the value of the form correctly.

Typed Reactive Forms

Moving forward, creating reactive forms will allow for specifying the type of the value of the form and the controls. For example:

const name = new FormControl('Preston Lamb');

Will create a new FormControl with the automatically inferred type of FormControl<string|null>. It can be null because by default, the reset method on the FormControl will set the value to null.

If you want the value to be non-nullable, you can use the initialValueIsDefault option when creating a FormControl:

const name = new FormControl('Preston Lamb', { initalValueIsDefault: true );

The name control can no longer be set to null; if it’s reset the value will go back to ‘Preston Lamb’ in this case (or whatever the initial value is set to).

You can also explicitly set the type of a form control:

const email = new FormControl<string>('', { initialValueIsDefault: true });

The email control has the same functionality as the above name control, with the exception of the default value being an empty string.

Another option for typing reactive forms is by providing an interface as the type for a FormGroup. Consider the following:

interface User {
  name: string;
  email: string;
}

const userForm = new FormGroup<User>({
  name: new FormControl(''),
  email: new FormControl('')
});

By typing the form like this, we ensure that no controls can be added or removed from the form. All the attributes of the interface that are not optional must be present on the form. Optional attributes of the interface can be added or removed later on.

Conclusion

Having type-safe forms in Angular apps is a good step in the right direction. The possibility of accessing an attribute that doesn’t exist, or setting the value of a control to an unsupported value, is removed if the form and its controls are typed. The developer experience of using reactive forms will be better with these types.

You can start using typed forms as of Angular v14

Angular Standalone Components

Preston Lamb — Mon, 18 Jul 2022 00:00:00 +0000

tldr;

For years, Angular has been organized and built on top of modules. These modules grouped functionality inside your app. Components, pipes, services, and directives that had related purpose were grouped together and declared inside modules, which would need to be imported in another part of the app to be used. This pattern works, and the organization for your component is nice, but it does complicate learning Angular for the first time. To get started with an app, a beginner has to learn what a component is and what a module is and how they work together. This makes it more complicated to jump in and get started. Standalone components coming to Angular is a big step towards simplifying different parts of your app, and simplifying the learning process.

Throughout this article I’ll use the term “standalone components”, but these same methods can be used with pipes, directives, guards, and other pieces of an Angular application that you would normally have to declare inside an NgModule.

What are Standalone Components?

A typical Angular component is created and added to the declarations array of an NgModule. If the component is not added to the declarations array, it cannot be used by any other components, whether inside that same module or another one (by importing the module in a separate one). Thus, we can see that components have been, up until now, tied to modules.

Standalone components are named this way because they “stand alone” from NgModules. They do not need to be included in the declarations array to be used in other places. Instead, the component itself is imported where it needs to be used. Now, components can be be created and used without an NgModule. You could, theoretically, build an entire application without a custom NgModule.

Example Standalone Component

Now that we know what standalone components are, let’s look at an example of one.

import { CommonModule } from '@angular/common';
import { Component, Input } from '@angular/core';

@Component({
  selector: 'app-name',
  standalone: true,
  imports: [CommonModule],
  template: `<h1>{{ name | titlecase }}</h1>`,
  styles: [
    `
    h1 {
      color: blue;
    }
  `,
  ],
})
export class NameComponent {
  @Input() name: string | undefined;
}

This component takes a name as an input and then outputs it on the page while title casing the string. For the most part, it looks just like any other component you’ve created in an Angular application. There are just a couple differences. First, we need to designate the component as standalone, which is done in the @Component decorator’s metadata with the standalone: true key/value pair. The other part that looks different from past components you’ve created is that there is an imports attribute in the metadata, where you can import NgModules and/or other standalone components to be used inside this component. In the above example, the CommonModule is imported so the titlecase pipe can be used.

To use this standalone component somewhere else, it needs to be imported. It can be imported in an NgModule or in another standalone component:

import { NameComponent } from './app/name.component';

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [
    NameComponent,
    CommonModule,
  ],
  template: `
  <app-name *ngIf="name" [name]="name"></app-name>
  `,
})
export class AppRootStandaloneComponent {
  name = 'preston lamb';
}

Bootstrapping an Application from a Standalone Component

In addition to creating normal standalone components that are used throughout the app, you can create a standalone component that is used to bootstrap the application. In the past, bootstrapping an application has been done by a module. That still works, and you can continue to use that method if you’d like. However, you can now use a standalone component as the root of the application. Let’s say we want to use the above AppRootStandaloneComponent as our root component for our app, and want to start the app with that component. We could bootstrap the app with the following code:

import { bootstrapApplication } from '@angular/platform-browser';

bootstrapApplication(ExampleStandaloneComponent)
  .then((ref) => {
        // do some stuff
  })
  .catch((err) => console.error(err));

This is similar to bootstrapping an application with a module, but it is slightly different. Both ways work and you can choose the way that you prefer.

What’s Next?

Standalone components are currently in developer preview only in Angular v14. You can try them out now, but they are not quite ready for prime time. In the coming months, we will see these become stable and be more frequently used in Angular applications.

Until then, it’ll be helpful to play with standalone components and understand what they are and how they’re used. If you’re a library developer, this may be especially helpful for you as you plan to upgrade your library

Shared Cypress Assets in an Nx Workspace

Preston Lamb — Mon, 16 May 2022 00:00:00 +0000

tldr;

Many times Nx workspaces have multiple applications, and being able to share custom Cypress commands between the end to end test projects. I spent several months manually copying these commands between the different projects, and would inevitably forget to update one when a change was made. Finally I decided to solve the problem and find a way to share the Cypress assets among the projects. This article will cover one way to do this.

To follow along, you'll need an Nx workspace with at least one end to end project.

Create the Shared Assets Library

Let's get started by creating a shared end to end assets library. This will be similar to creating any other library in an Nx workspace. The only potential difference will be the type of library you create. Nx provides a way to create Angular specific libraries, for example. In this case, we don't want to create a framework specific library. That can be accomplished with the following command:

$ nx g @nrwl/workspace:library e2e-assets --directory shared

This command creates a generic Nx workspace library called e2e-assets and puts it in the libs/shared directory. In this library we'll add custom Cypress commands which we can then use in all our end to end projects.

Create Custom Command File

Let's now add a file that contains a custom Cypress command in our new shared library. This custom command will make it easier to select elements by the data-cy HTML attribute. Create a file in the e2e-assets/src/lib folder called data-cy.commands.ts. Here are the contents of that file:

// data-cy.commands.ts

// load the global Cypress types
/// <reference types="cypress" />

declare namespace Cypress {
  interface Chainable {
    /**
     * Custom command to get elements by data-cy attribute.
     * @example cy.dataCy('greeting')
     */
    dataCy(selector: string): Chainable<Element>;
  }
}

Cypress.Commands.add('dataCy', (value) => cy.get(`[data-cy=${value}]`));

The first two lines of the file load the types for Cypress and prevent errors from showing in your IDE. The next portion of the file essentially extends the Cypress object for your tests by declaring the new custom command. If you leave this out and try to use the dataCy command you will get an error and the command will not work. The last line of the file is the code to actually add the custom command. The first argument to the Cypress.Commands.add method is the name of the new command, and the second argument is a callback function that provides the functionality for the custom command.

This custom command returns the cy.get method and selects an element by the data-cy HTML attribute. We'll look at how it's used later.

Importing the Custom Command

The next step is to import the new custom command so it can be used in our Cypress tests. The first import belongs in the e2e-assets/src/index.ts file:

// e2e-assets/src/index.ts

import './lib/data-cy.commands';

This makes the new command available when we import this library into our Cypress tests, which we'll do next. The second import belongs in the app-e2e/src/support/index.ts file. By importing the library here, this new command will be available in the app-e2e Cypress tests.

// app-e2e/src/support/index.ts
import '@my-org/shared/e2e-assets';

Now that you have imported your shared e2e assets library, you can use the new command.

Using The New Custom Command

Here's an example of using the new custom command in a Cypress test:

// app-e2e/src/integration/test.ts

it('should show the homepage', () => {
  cy.dataCy('homepage').should('be.visible');
});

If you didn't use this custom command, your test would like this:

// app-e2e/src/integration/test.ts

it('should show the homepage', () => {
  cy.get('[data-cy=homepage]').should('be.visible');
});

There's not a big difference here, but speaking from experience it gets tiresome to repeat the attribute selector each time you need access to an element based on the data-cy attribute. This simple custom command is much easier to use.

Conclusion

One of the biggest benefits of Nx workspaces is the ability to share code between projects. It's natural to share code between Angular or React apps, but the same process can be used to share code for your Cypress end to end tests. It becomes especially useful the more apps you have in your workspace, and for more complicated Cypress commands

Authenticating Your App for Cypress Tests

Preston Lamb — Wed, 20 Apr 2022 00:00:00 +0000

tldr;

Many Angular apps require the user to be authenticated before using the app. This can make writing and running Cypress end to end tests difficult. If your login flow requires you to leave the app to authenticate, the problem becomes even more difficult. This article will cover a solution to this problem and allow you to write your Cypress tests. The exact specifics of doing this will vary for each app, but each case should follow closely to the steps provided here:

Create a login Cypress command
Optionally, you can obtain a token from your auth server, and save it to localStorage (or sessionStorage, depending on your app)
Run the login command in the beforeEach hook

The app I implemented this in was using the angular-oauth2-oidc package for authentication, and our auth server is Identity Server 4.

Cypress Login Command

The first step is to create a Cypress command that we can run to make the app believe the user is logged in. You can either use a fake token if you don't plan on calling the API or you can get a real token from the auth server. Below is an example of getting the token from the auth server and storing it in localStorage. You may have to save the token in another location for your app.

// authentication.commands.ts

declare namespace Cypress {
    interface Chainable {
        /**
         * Custom command to setup login
         * @example cy.login()
         */
        login(): Chainable<Element>;
    }
}

Cypress.Commands.add('login', () => {
    const options = {
        method: 'POST',
        url: Cypress.env('authServerTokenUrl'),
        body: {
            client_id: Cypress.env('client_id'),
            client_secret: Cypress.env('client_secret'),
            grant_type: Cypress.env('grant_type'),
            username: Cypress.env('username'),
            password: Cypress.env('password'),
        },
        form: true,
        headers: {
            'Content-Type': 'application/x-www-form-urlencoded',
        },
    };

    cy.request(options).then((response) => {
        window.localStorage.setItem(
            'id_token_claims_obj',
            JSON.stringify({ /* userInfo object */ }),
        );
        window.localStorage.setItem('access_token', response.body.access_token);
        window.localStorage.setItem('id_token', response.body.access_token);
        window.localStorage.setItem('expires_at', '' + new Date().getTime() + 10 * 60 * 1000);
    });
});

Let's walk through the function together. The top portion of the code block, starting with declare namespace Cypress, declares the login method as part of the Cypress object. If you don't declare the login method like this calling cy.login() will result in an error. The next portion of the code block, starting with Cypress.Commands.add, adds the new login command to be used in your Cypress tests. An options object is created for making a call to the auth server to get a token. The request is made, and because it's a promise we can chain a .then method on to the request and get the returned data inside the callback. In my case, the token comes back on the response.body object as the access_token. Our app uses localStorage for storing the token so I store the token on window.localStorage. I also set the expires_at value and the user's info object. You may want to chain a .catch method on to the request where you can catch errors and log what happens. This will help you debug if the request fails.

All these values may have different keys in your application, but you'll likely need to set each value. I figured out which values were needed by logging in to the app and opening localStorage. I was able to see which values the auth package set in localStorage and then by process of elimination found the ones that were required for the user to be authenticated when the app loads.

If you want to use a fake token, you can remove everything from the login command except where the localStorage values are set. This method will work just fine if you don't plan on calling the application's API for any data.

Use the `login` Command

The next step is to actually use the login command you created. There are a couple of ways to do this, but the best way is to call the command in the beforeEach hook of your spec file.

// home.spec.ts

describe('Home', () => {
    beforeEach(() => {
        cy.login();

        // other test setup
    })

    // e2e tests
})

After I first created the login command I tried calling it in a before hook instead of beforeEach. That worked for the first test in the spec file, but localStorage is cleared by Cypress after each test. Because of that the app was no longer authenticated after the first test. Thus, make sure to call the login command in the beforeEach hook.

Cypress Environment Variables

Cypress has multiple ways that you can provide environment variables to use in your tests. There are a lot of ways to provide the environment variables you need to request the token, but I used the cypress.env.json file when running the tests on my local machine and provided the values on the command line when running the tests in our CI/CD pipeline. The cypress.env.json file is not committed to our git repo so that the secrets are not accidentally made public.

Conclusion

It took me a few hours to figure out the specifics of how to make the app believe the user was logged in, but this method works perfectly. We can mock all the data from the API and use a fake token, or we can use a real token and call our actual API

Detecting Idle Users in Your Angular App

Preston Lamb — Tue, 19 Apr 2022 00:00:00 +0000

tldr;

Occasionally the applications we work on need to react in a particular way if the user is inactive for a certain amount of time. For example, if the user is inactive for 5 minutes a popup should appear and ask the user if they want to stay logged in or if they want to log out. In this article, we'll look at a way to do that in your Angular app. We'll use two libraries to do this: @ng-idle/core and @ng-idle/keepalive.

Detecting Idle Users

To get started, let's import the necessary modules into the root AppModule:

// app.module.ts
import { NgIdleKeepaliveModule } from '@ng-idle/keepalive';

@NgModule({
    imports: [NgIdleKeepaliveModule.forRoot()]
})

Importing the NgIdleKeepaliveModule will get your application set up and ready to detect idle users. Next up, let's jump into the AppComponent, where the majority of the work will be done. We'll need to initialize a couple settings from the core module. Let's take a look, and then discuss.

// app.component.ts
import { DEFAULT_INTERRUPTSOURCES } from '@ng-idle/core';

export class AppComponent implements OnInit {
    private numberOfSeconds: number = 5;

    constructor(private _idle: Idle) {}

    ngOnInit() {
        this._idle.setIdle(numberOfSeconds);
        this._idle.setTimeout(numberOfSeconds);
        this._idle.setInterrupts(DEFAULT_INTERRUPTSOURCES);
    }
}

Let's look at these lines in a little more detail:

The setIdle method sets the amount of time to wait before determining that the user is idle. The value is provided in seconds. During this time, the application won't do anything with the idle user.
The setTimeout method determines how long the timeout lasts. In other words, using the example above, the application will wait 5 seconds before determining that the user is idle. At that point, the user will have 5 seconds (the length of the timeout) to register some activity in the application before the timeout expires.
The setInterrupts method takes an array of Events. These events interrupt the timeout and start it over. The defaults include mousemove, keydown, DOMMouseScroll, mousewheel, mousedown, touchstart, touchmove and scroll.

After these initialization values are set, we'll need to know when we should show or hide the warning or log the person out. I'll show you what I think are the most important events we'll listen to.

// app.component.ts

ngOnInit() {
    this._idle.setIdle(numberOfSeconds);
    this._idle.setTimeout(numberOfSeconds);
    this._idle.setInterrupts(DEFAULT_INTERRUPTSOURCES);

    this._idle.onIdleStart.subscribe(() => {
        // show the modal
    });

    this._idle.onIdleEnd.subscribe(() => {
        // hide the modal
    });

    this._idle.onTimeoutWarning.subscribe((secondsLeft: number) => {
        // Update the warning message
    });

    this._idle.onTimeout.subscribe(() => {
        // Hide the modal, log out, do something else
    });
}

Let's talk about each of these events in more detail.

The onIdleStart method fires when the user becomes idle. This is after the numberOfSeconds passed in to the setIdle method.
The onIdleEnd event fires when the user is no longer idle.
onTimeoutWarning fires each second for the duration that was provided to the setTimeout method. So, if you set that value at 5, the onTimeoutWarning will fire at 5, 4, 3, 2, and 1.
The onTimeout event fires when the specified amount of time has expired. This amount of time is the setIdle amount and setTimeout amounts.

With the above code in place, you should have everything you need to determine if a user is idle or not, and then to react to them timing out. The last step is to start the service that watches for the idle users. You can do that with the watch method:

ngOnInit() {
    . . .
    this._idle.watch()
}

The watch method starts the service and watches for the actions listed above. If you don't call this method, nothing will occur in the app and you'll definitely be left frustrated.

If you need to stop the timer, you can call the stop method if you want to turn the service off and stop watching for idle users.

Conclusion

This method of watching for idle users was a quick and easy way to accomplish the task. With this, I was able to wait until a user had been idle for a certain amount of time and then log them out if they remained idle. There are other things you could do as well, depending on your use case.

Share Interfaces in Angular and NestJS with Nx

Preston Lamb — Tue, 04 Jan 2022 00:00:00 +0000

tldr;

I'm a big fan of using Nx and having multiple apps in a single workspace, especially when the apps have a lot in common and a lot of code to share. This is especially helpful when dealing with interfaces for data retrieved from or sent to the server. In this article, we'll talk about how to share those interfaces between the front and back end.

This isn't the only way to manage these interfaces, but it is working well for us on a full stack project in our Nx workspace. An update can be made to the interface in one spot, and the front and back ends stay in sync. I've worked on a lot of projects where the communication breaks down and it's unclear what data should be sent or expected. That stumbling block can be eliminated by having your front and back end apps in the same workspace.

Setup

If you want to follow along, create a new Nx workspace:

$ npx create-nx-workspace

Give the workspace a name, and then select the angular-nest option for creating the workspace. After that you can enter what you want for the remainder of the prompts. Once the dependencies are installed, you should be good to go.

When you open the project, you'll see a couple directories inside the apps directory. The three directories are api, your Angular app folder, and the Angular app's end to end test folder. In the libs directory is an api-interfaces lib.

Creating an Interface

Let's create our first interface. It'll be a simple example, one that's frequently used: a todo. In the api-interfaces lib, create a new file called todo.interface.ts next to the api-interfaces.ts file that was created automatically when the workspace was created. Put the following contents in the new file:

// todo.interface.ts

export interface Todo {
    id: number
    title: string;
    complete: boolean;
}

This will be the base interface for the todos in our app. The Angular app will use this interface for type checking, and the API will implement this interface for the entities and DTOs that are used in NestJS.

Creating a DTO

Now that we have an interface, let's create a DTO that our NestJS app can use to define the data that should be sent when creating a new todo or updating an existing one. In the api app, create a new file: todo.dto.ts and add the following:

// create-todo.dto.ts

import { Todo } from '@my-workspace/api-interfaces

export class CreateTodoDto implements Omit<Todo, 'id'> {
    title: string;
    completed: boolean;
}

Note: in all likelihood you will not create this DTO in the api app, but in a new lib that you create for this NestJS module. To keep things simple for this demo, though, I selected the api folder to contain the DTOs and entities.

There are a couple things I want to point out here. First, we import our Todo interface from the api-interfaces lib, the one we created in the last section. This is the base for the DTO. We implement the interface to create our CreateTodoDto, but we use the Omit utility type to remove the id attribute from the DTO. The reason for this is because we won't have an id for the todo when we're creating it; that will be determined by the database. By using the Omit utility type and removing the id attribute from the DTO, we don't need to pass a null id when creating a new todo while at the same time requiring all the other attributes.

With this DTO now created, we can tell the controller what type to expect when a new todo is created. If an object with more or less attributes is passed to the endpoint, we can return a 400 with the required fields on the object.

Creating an Entity

Creating the entity is similar to the DTO, but we won't need to use the Omit utility type. Here's an example of the entity:

// todo.entity.ts
import { Todo } from '@my-workspace/api-interfaces';
import { Column, Entity, PrimaryGeneratedColumn } from 'typeorm';

@Entity('todo')
export class TodoEntity implements Todo {
    @PrimaryGeneratedColumn()
    id: number;

    @Column()
    title: string;

    @Column()
    completed: boolean;
}

The implementation here is very similar to the DTO, but we don't leave out the id. Instead, we mark it as the primary key and set it to be auto generated when a new todo is created. The other difference is the @Entity() decorator. This is required by typeorm to make this a table in the database where todos can be saved. Also, because the class is defined as TodoEntity, the table would be called todo_entity by default. By providing a string inside the parentheses for the Entity decorator, we can set the table name to todo.

I like to call the entity TodoEntity so that it's clear when I'm using it in different files that I am not using the interface. There are other ways, however, to distinguish between the two files and objects. Do whatever feels best to you!

The Benefits

So we just created three files for todos in our app. What's the benefit? Well, Angular is more powerful when types or interfaces or classes are used to determine how the data in your app is organized. You get auto completion from your IDE, and you're less likely to use the wrong attribute or method. In addition, with NestJS as our backend, we can easily check that the data that's sent to the backend is shaped correctly so that we don't have server errors popping up because too many attributes (or not enough) are sent along with the request.

The hard part is when you want or need these files on both the front end and the back end. Many times, those applications are in different repositories and managed by different teams. By having both applications in the same workspace, we've closed that gap. And, by having the DTO and entity implement the interface, we're assured that if the interface changes then changes will need to be made to the DTO and entity. Those two files will have errors if attributes are added or removed to the interface and they don't implement the right attributes. Thus, the shape of the data is always the same on the front and back end.

Conclusion

I hope this article helped you with knowing how you can manage the interfaces, DTOs and entities in your application. When starting this project, I was unsure of the best way to do this same thing. I got some ideas from Twitter, and then just started trying it out and came up with this method. I know there are other ways to do it; maybe even better ways. But this was a simple implementation and has worked great so far. Let me know how it goes for you

DEV Community: Preston Lamb

Git Worktrees In Use

tldr;

Cloning Your Repo

Adding a Worktree

Adding a Worktree with a New Branch

Add a Worktree Based on a Remote Branch

Updating a Worktree

Removing a Worktree

Listing Worktrees

Conclusion

Nx Conf 2022 Recap

tldr;

Generators

Component Testing

CI

General Conference Experience

RxJS: defaultIfEmpty

RxJS: defaultIfEmpty

tldr;

Background

defaultIfEmpty

Conclusion

Astro + Angular

tldr;

Background

Implement Angular and Astro

Conclusion

Reusable Component Pieces with ngTemplate Outlet

tldr;

Explanation of the Problem

Solution

Conclusion

Angular Lifecycle Hooks

tldr;

Angular Lifecycle Hooks

ngOnInit

ngOnChanges

ngAfterViewInit

ngOnDestroy

Conclusion

Angular Typed Reactive Forms

tldr;

The Issue

Typed Reactive Forms

Conclusion

Angular Standalone Components

tldr;

What are Standalone Components?

Example Standalone Component

Bootstrapping an Application from a Standalone Component

What’s Next?

Shared Cypress Assets in an Nx Workspace

tldr;

Create the Shared Assets Library

Create Custom Command File

Importing the Custom Command

Using The New Custom Command

Conclusion

Authenticating Your App for Cypress Tests

tldr;

Cypress Login Command

Use the login Command

Cypress Environment Variables

Conclusion

Detecting Idle Users in Your Angular App

tldr;

Detecting Idle Users

Conclusion

Share Interfaces in Angular and NestJS with Nx

tldr;

Setup

Creating an Interface

Creating a DTO

Creating an Entity

The Benefits

Conclusion

`defaultIfEmpty`

`ngOnInit`

`ngOnChanges`

`ngAfterViewInit`

`ngOnDestroy`

Use the `login` Command