Forem: Chandler Baskins

Moving Material Dialog Lifecycle Into NgRx Effects

Chandler Baskins — Tue, 19 Oct 2021 23:02:37 +0000

NgRx Effects

Effects are a powerful model for handling side effects in your application. Commonly this means when you are making a HTTP request in a NgRx powered application you will use an effect to handle the communication with the service but they can do so much more than that. And frankly this is what I usually used them for until I read https://timdeschryver.dev/blog/start-using-ngrx-effects-for-this#handling-the-flow-of-a-angular-material-dialog .

I became intrigued by the idea of offloading some component material dialog code into the effect and started viewing the life cycle as a series of events and using the effect to talk to other effects. This can keep components more simple and pure where they use selectors to read data and dispatch actions in response to events. When components are pure and simple this makes them easier test and easier to change when future requirements are different. This was a motivator for me to start looking down this path but first I wanted to make sure to follow some common best practices and make sure that I wasn't creating an anti-pattern.

Some Effects Best Practices

This isn't an exhaustive list but rather some tidbits of gold I capture from the worlds most interesting man, Mike Ryan from the NgRx Core Team from this episode of The Angular Show https://open.spotify.com/episode/6YSwV2WqiZddt2F16jTQ1M?si=_BqOD8fVRYyIOEZuEdV3ug&dl_branch=1

Effects should be the only thing that calls your HTTP Services

This one is straight forward and makes alot of sense.

Use the right Higher Order Mapping Operator and if you don't know use concatMap

This is a good one. But I would also point out that you may not need one if your not returning inner Observables and beware of backpressure.

If you need store information in your effect use concatLatestFrom

This one is probably one of the most important. The concatLatestFrom operator handles store selectors (Observables) in a more intelligent way. It will only subscribe to them when your effect is processing it's action (lazy). The withLatestFrom operator will always subscribe to the selector forcing the selector to stay hot and compute even if your not in that part of the app. This operator is almost a drop in replacement and a easy performance gain.

Break up big effects by creating multiple smaller ones that listen to the same action

The actions stream which effects subscribe to multi casts its values, the ofType operator helps us decide which one we are interested in for this effect. So with that being said make many small operators that handle one side effect.

Effects talk to other Effects via Actions

Not really a best practice but its good to know. NgRx is all about indirection and Actions are the communication mechanism that drives communication through the indirection. This is also how Effects talk to Reducers. Important to note that Reducers don't talk but only listen.

Common Material Dialog Lifecycle

Now that we have a good understanding of effects lets look at a common material dialog life-cycle.

To interact with Material Dialogs you'll need to inject it into the host(?) component. With that service comes methods for interacting with the dialog such as opening it.

//app.component.ts
@Component({
  template: `...`
})
export class AppComponent {
    constructor(private dialog: MatDialog) {} 
    //click handler when we wanna open the dialog
    openDialog(){
        const configData = {} //whatever we wanna give our dialog
        const dialogRef = this.dialog.open(DialogComponent,configData)
    dialogRef.afterClosed().subscribe(data => {
            this.doSomethingWithData(data)
        })
    }
}

//dialog-component.component.ts
@Component({
  template: `...`
})
export class DialogComponent {
    constructor(
        public dialogRef: MatDialogRef<DialogOverviewExampleDialog>,
        @Inject(MAT_DIALOG_DATA) public data: DialogData)
    ) {}
    save(data){
        this.dialogRef.close(data)
    }
}

Now this is a pretty contrived example but it illustrates simply what the life-cycle is usually like with a dialog. Breaking it down we inject the service for Mat Dialog. Then we have a click handler method that handles the button click and opens the dialog with data we want to give the dialog component. In the Dialog Component we inject a reference to the opened dialog and inject a Token that carries the data that we passed the dialog. Then when the user wants to save we close the dialog and give it some data.

Back in the host component when we call open that returns the dialog reference of the opened dialog. This reference has a after closed method on it that returns an observable that carries the data that we gave it when we called close on the dialog reference in the Dialog Component. With this data we do whatever we want usually somewhere downstream making a HTTP call that posts the data back to the server.

Now this is a contrived example but it can be a bit confusing. In the openDialog method on the component we do more than just open the dialog. We handle the whole life-cycle of the dialog and handle the end result which is getting data back from the dialog and then doing something with. This can make testing this component and this method a little more complicated than it could be.

Viewing the Life Cycle as a series of events to be handled by Effects.

Now that we know our prerequisites its time to get into the point of this post. We know the life-cycle of a dialog which is open ⇒ interaction(save or cancel) ⇒ dialog close so lets model these life-cycles with the appropriate actions first

//dialog.actions.ts
const dialogOpened = createAction(
    '[Home Page] Dialog Opened', 
    props<{component:unknown, data:unknown}>()
)

const dialogSaved = createAction(
    '[Home Page] Dialog Saved', 
    props<{data:DataToSave}>()
)

const dialogClosed = createAction(
    '[Home Page] Dialog Closed', 
    props<{data:DataToClose}>()
)

Definitely don't type your stuff as any if you can avoid it. Although I couldn't find a way to type components and the data could look different depending on your situation

Next we create our effects that are listening for these actions

//dialog.effects.ts
@Injectable()
export class DialogEffects {
    constructor(private actions$: Actions){}

    saveDataSuccess$ = createEffect(() => this.actions$.pipe(
        ofType(DataActions.SaveDataSuccess),
        map(response => DialogActions.dialogClosed(response))
    ))

    dialogOpened$ = createEffect(() => this.actions$.pipe(
        ofType(DialogActions.dialogOpened),
        tap(payload => {
            this.dialogRef.open(payload.component,payload.data)
        })
    ),{dispatch:false})

    dialogSaved$ = createEffect(() => this.actions$.pipe(
        ofType(DialogActions.dialogSaved),
        map(payload => DataActions.SaveData(payload))
    ))

    dialogClosed$ = createEffect(() => this.actions$.pipe(
        ofType(DialogActions.dialogClosed),
        map(payload => {
            this.dialogRef.closeAll();
            return snackBarActions.savedSuccessfully(payload)
        })
    ))
}

Two important things of note here. The first is the {dispatch:false} on the dialogOpened$ effect. We use this to tell NgRx that we are not going to have any actions coming out from this effect. If we didn't use this we would end up in a infinite loop with a warm computer and a crashed browser. Second notice that I have an effect that is listening for the Success action that would have been dispatched upon completion of a successful HTTP request. We use this to dispatch the dialogClose action because we don't wanna close our dialog until the data has been saved or at all if there is an error.

Finally in our components its as simple as dispatching the appropriate actions


//app.component.ts
@Component({
  template: `...`
})
export class AppComponent {
    constructor() {} 
    //click handler when we wanna open the dialog
    openDialog(){
        this.store.dispatch(DialogActions.dialogOpened({component,data}))
    }
}

//dialog-component.component.ts
@Component({
  template: `...`
})
export class DialogComponent {
    constructor(@Inject(MAT_DIALOG_DATA) public data: DialogData) {}

    save(data){
        this.store.dispatch(DialogActions.dialogSaved({data}))
    }
}

Testing is now a bit easier

Now that we have offloaded some code from our components to our effects testing is a bit easier. We've been able to remove some dependencies from our component so we don't have to mock them in the tests anymore and to unit test these methods we simply assert that the dispatch action was called with what we expect.

describe("DialogComponent", () => {
    let component: DialogComponent;
  let fixture: ComponentFixture<DialogComponent>;
  let store: MockStore;

  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [ReactiveFormsModule],
      declarations: [DialogComponent],
      providers: [
        { provide: MAT_DIALOG_DATA, useValue: data },
        provideMockStore(initialState),
      ],
    }).compileComponents();
  });

  beforeEach(() => {
    fixture = TestBed.createComponent(DialogComponent);
    store = TestBed.inject(MockStore);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });
    it("should dispatch save action with form data", () => {
        const storeSpy = spyOn(store,"dispatch")
        component.save(formData)
        expect(storeSpy).toHaveBeenCalledWith(DialogActions.dialogSaved(expectedData))
    })
})

Again this is a contrived example but I hope it can demonstrate how offloading code from our components makes them more easier to test. When we make our components more easier to test we make the barrier to entry lower for testing. Asserting the dispatch method was called with the appropriate action could be the only thing for this method anything else needs to be handled by the effects unit test. Here is what our effect test could look like

describe("DialogEffects", () => {
    let actions$ = new Observable<Action>();

    TestBed.configureTestingModule({
      providers: [provideMockActions(() => actions$)],
    });

    describe("dialogSaved$",() => {
        it("should dispatch action to save data",(done) => {
            actions$ = of(DialogActions.dialogSaved({data}))
            dialogSaved$.subscribe(result => {
                expect(result).toBe(DataActions.saveData)
            })

        })
    })
})

Conclusion

To close I like Tim find writing the life-cycle of a mat dialog a lot easier when its moved to the effect model. With the compos-ability of effects you can easily build complex features. This offloads some logic into our effect model keeping our components lean and simple and easy to test.

Reactive Forms in Angular

Chandler Baskins — Thu, 26 Aug 2021 13:43:08 +0000

Photo by SIMON LEE on Unsplash

Forms can be complicated

Seriously. I feel like the days of wysiwig forms are over. Long gone are the days where we have our HTML form and then do a post back to the server with our form data. These days we need to do real time validation like is this username taken. Or we need to have dynamic forms like a Registration form where we can select how many people to register and the fields populate based on our response. This is powerful stuff. This becomes a form that is driven by the user. Kinda like a RPG, no two users may have the same experience and the form populates according to their responses or actions. But with better UX comes more complications for the developer. Thankfully Angular being the kitchen that it is serves us up something tasty for building these complicated forms. Reactive Forms.

Reactive Forms

Per the wonderful documentation

Reactive forms provide a model-driven approach to handling form inputs whose values change over time. Reactive forms are built around observable streams, where form inputs and values are provided as streams of input values, which can be accessed synchronously.

I love these model driven approaches and I love RxJS so I usually feel right at home here. One question I asked was how do I represent that model in my code and how does that translate to the HTML that renders the controls (inputs,radios,selects) on the screen? Well as a basic building block Angular, provides us with Abstract Control https://angular.io/api/forms/AbstractControl. This is the Base class that the Reactive Forms API builds on top of. This class contains properties and methods for handling the value of your form control as well as validation and form state (dirty, pristine, valid, invalid). A building block built on top of this is the Form Control https://angular.io/api/forms/FormControl#formcontrol. This is our basic building block to create a single form control. For example

// in your component
const firstNameControl = new FormControl({value: 'any init value or null', disabled: false},[Validators.required],[myCustomAsyncValidator])

Now instantiating this class takes three arguments. The first is a seed value which can be a config object or just an init value, second an array of or a single synchronous validator(here I'm using a buiilt in validator for requiring), and third an array or single async validator that is a custom validator. You can also pass in a config object here as well with properties for both kinds of validators. Now to bind this to a HTML element we need to bridge the gap from the template to the class. We do this with a directive that ReactiveForms provides called formControl we'd use it like this

<label for="name">First Name: </label>
<input id="name" type="text" [formControl]="firstNameControl">

Now usually we don't just don't have single controls. Usually forms are made up of multiple inputs for a user to fill out. Thankfully Angular provides us a way to group controls with FormGroup. From the docs

A form group defines a form with a fixed set of controls that you can manage together. Form group basics are discussed in this section. You can also nest form groups to create more complex forms.

An example of a FormGroup would be

profileForm = new FormGroup({
    firstName: new FormControl(''),
    lastName: new FormControl(''),
  });

Here we instantiate the FormGroup class and give it an object whos keys are the names of our formControls and whos value is the FormControl class itself. This makes it easy for us if we need to check for validity as a whole (you have to fill out the whole form before you submit). The AbstractControl class also has a method that allows us to query for a child control. We can do this like so

const firstNameControl = this.profileForm.get('firstName');

Honestly AbstractControl could have a whole article written on it, Definitely helps having a good understanding on it and the API Reference is a great place to start.

Now to bind to this form group in our template we will use the formGroup directive.

<form [formGroup]="form" (ngSubmit)="onSubmit()">
      <div *ngIf="first.invalid"> Name is too short. </div>

      <input formControlName="first" placeholder="First name">
      <input formControlName="last" placeholder="Last name">

      <button type="submit">Submit</button>
   </form>

Now here you may notice for our individual controls we are using formControlName Because our controls are linked to a FormGroup and are not class members formControl would not be able to find them. Remember the [] in Angular is for property bindings. formControlName is smart enough to know that it's in a formGroup and will attempt to find the control from that group. There are directives that will sync nested Form Types (Array,Control,Group). You can find the API Summary here https://angular.io/guide/reactive-forms#reactive-forms-api-summary.

Dynamic Forms and Form Array

Dynamic forms are one of the coolest user experiences you can have on the web. Selecting this option populates more form fields while selecting this option takes you to the end of the form. It makes things feel like a living interaction. Angular provides us with FormArray https://angular.io/api/forms/FormArray. You can also use FormGroup and add controls to it dynamically but the benefit that FormArray provides is that the controls are unnamed. This is also useful for pushing in FormGroups and allows for complicated nesting to be easier for us because FormArray comes with methods like push, insert, removeAt etc... that are similar APIs that we are already familar with when working with Javascript Arrays.

If we take a registration form for example we may have setup our form model to look something like this

registrationForm = new FormGroup({
    employees: new FormArray([this.newEmployee()])
  });

  addEmployee() {
    this.employees.push(this.newEmployee());
  }

  newEmployee() {
    return new FormGroup({
      firstname: new FormControl('', Validators.required),
      lastname: new FormControl('', Validators.required),
      jobTitle: new FormControl('', Validators.required)
    });
  }
  get employees() {
    return this.registrationForm.get('employees') as FormArray;
  }
  submit() {
    console.log(this.employees.controls[0].value);
  }

Here we have a newEmployee method that is just a factory function returning a FormGroup class. I put this in a method because it's nice having a config in one place instead of having it initialized in the registrationForm declaration and then when we add a new employee. Any time we want to add a new employee we simply call this method. I also initialized our Form Group with a new Form Array that call athis method so we have one group for a new employee. I added a getter for convenient access to the Form Array.

<form (ngSubmit)="submit()" [formGroup]="registrationForm">
  <section class="employees" formArrayName="employees">
    <ng-container *ngFor="let employee of employees.controls; let i = index;">
      <div class="employee" [formGroupName]="i">
        <input class="input"  formControlName="firstname" type="text">
        <input class="input" formControlName="lastname" type="text">
        <input class="input"  formControlName="jobTitle" type="text">
      </div>
    </ng-container>
  </section>
  <button type="submit">SUBMIT</button>
</form>
<button (click)="addEmployee()">Add Employee</button>

Here we have our mark up and directives for rendering the form and connecting it with our model. To start we use the form element and bind the group to it. Next we access the employees Form Array using the formArrayName directive. This directive is smart enough to look into the object and grab us the form array with that name. Next we iterate over the array outputting our form group. Since these controls are unnamed we bind to them using the index of the array we iterated over and use the formGroupName directive and compute it's value. Lastly we bind to the controls of the formGroup using formControlName This setup allows us to add new controls but what if we wanted to remove them? Well FromArray offers us a removeAt method that needs the index of the item we want to remove. You don't want to modify the array that was used to instantiate the form array directly as strange behavior can occur.

Adding and Removing Controls based on input

This one gets kinda fun because your listening for user input and then doing something with. Fundamentally it's similar to reacting to button clicks to add more controls or remove them. Instead of listening to click events we listen to user inputs and we can do that using the valueChanges property from the Abstract Control class. valueChanges is a multicasting observable that emits an event every time the value of the control changes, in the UI or programmatically. This means calling set or patch value will cause an emission unless you pass {emitEvent:false}

So the recipe here would be listening for input and then using that input to add or remove controls based on that input.

control.valueChanges.subscribe(value => {
    if(value === 'whatever') {
        this.addNewEmployee()
    }
})

Here we are checking if the value meets a condition and then calling a method that ends up pushing more controls into the form array. This is one way to do it and a straightforward one because our template is already iterating over the Form Array so we have nothing left to do on our end. If we were just adding a new control to the whole group there is a addControl method that we would use. Then we would need to set up the template to look for a form control with that name and only show the elements if the control exists.

Declarative, Reactive, Data and Action Streams in Angular

Chandler Baskins — Mon, 12 Oct 2020 15:59:02 +0000

First things first

Let's go ahead and get introductions out of the way. I'm Chandler, a full-stack dev from Alabama, US focusing on Angular and web technologies. Currently, I'm on the Engineering Team at nSide, The School Safety Platform, where I'm currently building IOT dashboards for various devices.

TLDR;

We can use action and data streams declaratively to react to user actions. Leveraging the power of RxJs operators we can transform our data and allow our template to subscribe to the Observable using the Async pipe. Here's a StackBlitz...

That title has a lot of big scary words

I get it if you're new to Angular that sentence could be overwhelming, What does reactive mean? What is declarative? Ok, data fetching I get and I know about the HTTP Client but what are you talking about? Well first let's nail down some key terms, some basic fundamentals, and then let's iterate from there. In this article, I hope to take you to the beginning of the journey I'm still going through. Let's get started!

HTTP Client

There are some basic assumptions that I'm making here. First, I assume you know Angular up to this point in the docs https://angular.io/tutorial/toh-pt6. Second, this isn't going to be an in-depth post on RxJs that would require a series of posts that I'm definitely not qualified TO teach, but I do assume some basic knowledge of things like Observables, Subjects, and subscribing.

So typically in Angular applications, you'll need to get some data from a server and display it for your users to read and interact with. Most of the time we'll use methods like ...

getUsers() {
    return this.http.get<Users[]>(`${this._rootUrl}/users`)
        .pipe(catchError(err=> (
            this.handleError(err)
    ))
}

Following good practices, this method lives in our service and then is called in our component when the component is initialized.

ngOnInit(): void {
//dont forget to unsubscribe! 
    this.subcription = this.userService.getUsers()
        .subscribe(res => this.users = res)
}

Then with the users property in our class, we can use structural directives in our template and display our UI.


<div *ngFor="let user of users">{{user.name}}</div>

This is a completely valid way, but is there a better way?

This is the question I started asking myself. There are a few improvements that could be made. I can think of one specifically by using the Async Pipe to subscribe to the observable so I don't have to manage my own subscriptions. That in of itself is a huge win and makes this a technique that a lot of people use. But I wasn't satisfied and I ran into this problem at work that involved taking data from two different APIs. Using a procedure like pattern didn't feel like the solution to me. Then I saw a talk from Deborah Kurata and was hungry to learn more. Enter in the Declarative and Reactive approach.

Key Terms

First, let's talk about what reactive and declarative mean. For starters, we may recognize the imperative or procedure like way of coding. This is where you describe each and every step of what you want to accomplish. For instance say you want to navigate to a particular file in your filesystem that's nestled deep in a folder structure. You don't remember what's all in there and you can only use the terminal. You're going to be doing a lot of ls and cd until you get where you need to go. Those are procedures. You're describing exactly each step until you get to where you wanna go. Now, what would a declarative approach look like? Simply saying whatever-the-file-is and then the machine figures out the rest by itself. This is nice if the machine knows how to do it but most of the time it does not and we need to describe what we want to happen and all the steps to achieve that. Now reactive programming is a bit harder to explain and I think I'll punt to this article https://gist.github.com/staltz/868e7e9bc2a7b8c1f754
But the short of it is...

//C REACTS to changes in a or b
let a = 1;
let b = 2;
let c = a + b; //3 at this point in time
b = 3;
// C will now be 4. It recomputed its value based on changes to the things that make up its value.

Declarative Data Streams

Now that we know where we have been let's talk about where we are going. Let's declare a data stream.

allUsers$ = this.http.get<User[]>(`${this._baseUrl}/users`).pipe(
    map(users =>
      users.map(
        user =>
          ({
            ...user,
            username: `${user.username}@${user.website}`
          } as User)
      )
    ),
    catchError(err => {
      console.error(err);
      return throwError(err);
    }),
    shareReplay(1)
  );

So let's do a breakdown of this code. In our service, we are declaring a property in our class called allUsers$. Now the $ at the end is a community convention to let you know that this is an Observable stream. Leveraging RxJs operators we could do any kind of data transformation that we want but in this case, I'm using the map operator to receive that User[] value, Array.map() over every User object and then return a new object with a new property called username. Then we cast that return value back as User for good measure in case our typings got messed up and TS couldn't infer the type. Next, we do some error handling with catchError. Now typically you'd log it using a Logger service and keep the logs on a server somewhere but for now, we will just error in the console. I do this here so if there was a problem we could see in the service where it was and then we return throwError so that it propagates up to the object that subscribes to it (our component) and they can handle it there. Lastly, we shareReplay(1). This allows us to cache and reuse the data we've already got if someone subscribes to the Observable later on. For instance, say we have two components that subscribe to the Observable at different times. The first subscriber will kick off the HTTP request. Since we are sharing and replaying the result, the next subscriber gets the value the first one did and another HTTP call does not have to be made.

How to use Data streams

Using a data stream is incredibly simple! Here is a recipe for using the stream,

Inject the service into the target component using private userService: UsersService
Capture a reference of the data stream from your service. For example.

this.users$ = this.userService.allUsers$.pipe(
//Our error thrown from the service bubbles to the component where we handle
//it. I'm just simply setting a property to true
//You have to return an Observable so I just return a empty observable that completes
      catchError(err => {
        this.error = true;
        return EMPTY;
      })
    );

Now we subscribe from our template with the Async pipe!

<ng-container *ngIf="users$ | async as users">

Reactive Data Streams with Action Streams

Some of the times our data in our applications is read-only. This makes things easy for us because we just subscribe to the Observable and display the data in the template and call it a day. Other times we want our users to have the ability to modify the data or take actions on that data. We can call these user actions Action Streams. We can create action streams using RxJS Subjects and throwing values into those streams. Taking an action stream we can have our data stream react to those actions and leverage RxJs operators to modify our data. Here's an example of declaring an action stream that emits a selectedUser.

private selectedUserSubject = new BehaviorSubject<number>(null);
  selectedUserAction$ = this.selectedUserSubject.asObservable();
  onSelectedUser(id) {
    this.selectedUserSubject.next(id);
  }

To break this down we have our BehaviorSubject that emits numbers and its Observable counterpart. We then have a helper method that when called from the component emits the ID of the selected user into that action stream. Using this information combined with the allUser$data stream we can create a stream that emits the selected user and reacts to the user's action.

selectedUserData$: Observable<User> = combineLatest([
    this.allUser$,
    this.selectedUserAction$
  ]).pipe(
    map(([allUsers, selectedUser]) => allUsers.find(u => u.id === selectedUser))
  );

We set the selectedUserData$ property to be the result of the combineLatest operator. What this does is takes the last value emitted from both streams and return those values as an array. Using array destructuring in the map operator we return the result of the allUsers array find function. So now every time we emit a new ID into the action stream this pipe runs returning us a new user.

Thanks for sticking around! I'm trying to get into writing more so if you have any tips or things I can improve on please let me know!

Let's Learn Angular!

Chandler Baskins — Tue, 05 May 2020 18:16:15 +0000

Edit 10/12/2020:
I fully intended on this being a series but then Corona Virus happened and I had a baby! Reflecting back I think I was biting off more than I could chew especially being a new writer and being new to Angular at the time. Looking forward, I'm back to writing again but I think this time it won't be in the format like this article. Stay tuned!

Hello! I'm Chandler and I'm a Web App Dev from Alabama! I've been a dev for about a year now at a awesome company called nSide. I don't write much but it's been something that I want to start getting into so excuse all these grammatical errors! As a bonus it will help solidify what I'm learning and teaching something you are learning has many benefits. Here are some great links by Michael Simmons. here's one ---- and another
(I love Michael Simmons work lol)

So what are we learning?

I'm going to start a series on Angular 9! I want to try something new and I like typescript, classes and OOP so why not. As a disclaimer I'm assuming you know enough JS, HTML and CSS to make pages and do some DOM manipulation. Angular uses typescript but you can pick it up as you go along.

First if you have been under a rock for the past decade Angular is a modern JavaScript framework for creating the client side of web apps. I emphasize framework because it is a true framework. Comparing it to another popular abstraction like React, React is a UI library, the sink in the proverbial kitchen. Angular is the whole kitchen. It has everything you need from forms to routing to animations. OK now that's out of the way lets get started shall we??

Angular CLI

I first started with React and its the only abstraction I know to do UI with JavaScript so a lot of my comparisons are going to be with it. But if your just starting out and don't know anything about either than I got you cover.
So how do we get started?
First lets get the awesome Command Line Interface tool that Angular provides for us

npm install -g @angular/cli

Compared to React you have to download the CLI globally on your machine. Most people will use the npm package running tool NPX to generate their React app via create-react-app.

If you've never used create-react-app than here's a primer for the CLI. The Angular CLI is an amazing tool. It generates different things for you. Things like (components, directives,modules,services) but more on these later. It also generates the workspace you need to create and develop your app. A workspace is the file structure and directories needed to create your app.
Angular guide on workspace.

Think about it like this, Angular is the whole kitchen but you don't have your kitchen yet. The CLI are the workers that come and install all your appliances and cabinets and all the things you need to create yummy dishes.
(Like Peach Cobbler)

To get those workers to build that kitchen, similarly to create-react-app you need to run in your terminal...

ng new project-name

The CLI will ask you questions for routing and styling language. For now lets just go with the default of CSS and no routing.
This like create-react-app generates all the files and dependencies you need.
Here is your new kitchen!

Now the only folders and file we care about right now are the src/app/app.component.html|ts|css|spec or app.module. These files are where the magic happens. These are where everything else descends from. Kinda like in React this is the main Component that everything descends from.

Now to compile our project and see what the default boilerplate gives us we run..

ng serve --open

ng serve starts up our local development server and compiles all of our angular code (the typescript,css,html) into vanilla css,js,html that the browser understands.Think about this command as taking all the ingredients for our peach cobbler and putting it in the oven. What comes out is that default boilerplate app. Now you may be wondering what that --open is. That's a flag that just tells the CLI to go ahead and open our default browser tab at our localhost.

I think we may be running long so lets recap!

We learned 2 commands with the CLI, ng new and ng serve.
Ng New tells the CLI to build our workspace(kitchen). Ng new takes our ingredients in our kitchen and throws it in a oven and out pops our Application.
We learned that the CLI genereates a workspace for us and that a workspace is the files and folder structure where we build our Angular applications.

Part 2

For part 2 we are going to talk about what makes up the ingredients of a Angular application. We're going to talk about what all those files are in our kitchen and what are components and how all this relates together. If you like where this series is going or if I missed something let let me know in the comments below!