How to handle modals "declaratively/reactively" with Angular (and is it any better?)

My modern Angular course: angularstart.com/
In this video, we take a look at two ways to handle coding the same modal in an Ionic and Angular application - one declarative and one imperative. The imperative example mostly utilises writing logic in the component's class, whereas the declarative example utilises properties on the component in the template.
Get weekly content and tips exclusive to my newsletter: mobirony.ck.page/4a331b9076
Learn Angular with Ionic: ionicstart.com
Source code: github.com/joshuamorony/ionic...
0:00 Simple Imperative Example
1:29 Simple Declarative Example
4:01 Simple Comparison
4:37 Advanced Declarative Example
7:30 Advanced Imperative Example
8:52 Conclusion
More on imperative vs declarative: • Why you should care ab...
More on the Quicklists app: • How far have I come in...
#ionic #angular #rxjs
- More tutorials: eliteionic.com
- Follow me on Twitter: / joshuamorony

[@JoshuaMorony]

Join my mailing list for more exclusive content and access to the archive of my private tips of the week: mobirony.ck.page/4a331b9076

[@mfpears]

Awesome! I looked at the 3 most popular component libraries for the 10 most popular front end frameworks, and Angular was THE ONLY ONE that opened and closed dialogs imperatively! The one exception was Ionic for Vue, but I ignored it because Ionic started with Angular and I didn't want to explain that in my article... I don't think KZbin likes links in comments, but it's called "Wrapping imperative APIs in Angular". Anyway, I have never seen a good reason not to have dialogs managed declaratively. It makes using observables much nicer.

[@valcron-1000]

Even though I really enjoy working with reactive stuff I prefer the imperative approach for this use case. I rather have my complexity in JS code than in the template where I don't really have a programming language.

[@mfpears]

You can add messy imperative code on top of this declarative API if for some reason you see the need: this.open = true

[@kaibe5241]

You can simplify a lot of the template though by writing helper methods, thereby using more of the TS language.

[@rtsinevich]

With declarative approach you need to keep in mind that component in the template lives even when it’s hidden. So if the dialog is a bit complex there might be a situation that while it’s not visible the input might be changing and executing some code that will lead to side effects.

[@mikefellowes8910]

Another great video Josh :) How would you handle ion-alert declaratively, since it doesn't seem to support template declaration in Angular?

[@JoshuaMorony]

I would just use the standard imperative API

[@MarioPineda94]

Thanks for the great content! How would you use Material's Dialogs? More specifically how would you handle the afterClosed Observable? I am debating either by removing the afterClosed observable from my logic (to avoid subscribing to it manually) but that would mean making my dialog component smarter performing the action itself. I am inclining more towards a dumb dialog component which I can reuse (for example a simple confirmation dialog) and manually subscribe to the afterClosed Observable so I can have that reusability on my dialogs.

[@MarioPineda94]

Update: I ended up using NgRx effects. An action will open the material dialog, and then the action will trigger an effect which uses switchMap to change to the afterClosed observable of the dialog reference. Inside that switchMap I dispatch a new action according to the dialog response. Something like this: deleteItems$ = createEffect(() => this._actions$.pipe( ofType(deleteItems), withLatestFrom(this._store.select(selectItems)), map(([action, selection]) => ({ dialogRef: this._dialog.open(ConfirmationDialogComponent, { data: { message: `Are you sure you want to delete ${selection.length} item${selection.length > 1 ? 's' : ''}` } }), selection })), switchMap(({ dialogRef, selection }) => dialogRef.afterClosed().pipe( filter((result: boolean) => result), // Confirm or cancel response switchMap(() => this._itemsService .deleteItems(selection.map((element) => element.id)) .pipe( map(() => getItemsAction()), catchError((error) => of(deleteItemsFailure({ error }))) ) ) ) ) ) );

[@Dorchwoods]

I find it difficult sometimes using event emitters when emitting an event from a child back to a parent. For example, the dialog emitting to the parent that it's closed. The concept makes perfect sense, but coming into a new app that I've never seen and trying to "trace" back all those events and trying to figure out what they're doing can be a pain. Anyone else feel that way?