DEV Community: Julian Dierkes

Automatically sync url path and query params with Angular component fields

Julian Dierkes — Sun, 25 Jul 2021 14:23:02 +0000

Wouldn't it be nice if a user of you Angular application could just send a link to another person ant they would end up seeing the exact same things on his screen?
The user could also just bookmark the url and get back to the same view whenever he wants to.

Using the Angular router you can accomplish that even if you have very dynamic views.
However, the effort and boilerplate code for this is quite huge and can easily be avoided with a library I wrote. (My first npm package ❤️)

The concept behind this is deep linking.

What is deep linking?

If you are already familiar with deep linking and how to implement it with the Angular Router continue here.

Imagine you have built a webapp for a library, and a user is browsing a list of available books. He selects a book and wants to show it to a friend.

With deep linking the information of the selected book is part of the url and can easily be shared between users. The same thing can be done with any parameter that affects the current view in your Angular application. (e.g. additionally with a search string as shown below)

As shown in the example above you can write these parameters to the url as

path parameter library/:location/books/:selectedBookId or
query parameter ...?searchString=jon&secondParameter=1.

Path parameters can be strings or numbers while query parameters also could be complex json objects

How to implement "deep linking" with the Angular router?

In your components you can get the current path and query params by injecting the ActivatedRouteSnapshot:



export class YourComponent implements OnInit {
    private yourPathParam: number;
    private yourQueryParam: string;

    constructor(private readonly activatedRouteSnapshot: ActivatedRouteSnapshot) {}

    ngOnInit() {
        const pathParams: Params[] = this.activatedRouteSnapshot.params;
        this.yourPathParam = pathParams['yourPathParam'];

        const queryParams: Params[] = this.activatedRouteSnapshot.queryParams;
        this.yourQueryParam = queryParams['yourQueryParam'];
    }
}

You can even subscribe to changes in the url params by using the ActivatedRoute instead of the ActivatedRouteSnapshot:



this.activatedRoute.params.subscribe((newPathParams) => console.log(newPathParams));
this.activatedRoute.queryParams.subscribe((newQueryParams) => console.log(newQueryParams));

What about the other way around? If a field in you component changes you can navigate to the new url by injecting the Router:



this.router.navigateByUrl(newUrl);

The hard part here is figuring out the new url. You might not want to change existing parameters but ony change the one that is of interest in your component.
However, this is a crucial part for implementing "deep linking" as we need an updated url whenever the view changes.

The downsides of the Angular router

As you can see synchronizing of url params with your component fields is quite hard and requires a lot of "boilerplate code".

The problems of the Angular router are

not providing a way to linking url parameters to component inputs via configuration
- A github issue for this requirement exists since 2017
not providing a simple way to update the url on component field changes (e.g. via component outputs)

The simple way with ngx-deep-linking

What if you could simply configure synchronization of component fields with the url?
Ngx-deep-linking provides a way to do this in the route configuration.

In the end you just need three things:

You need to install @jdrks/ngx-deep-linking:
- npm install @jdrks/ngx-deep-linking or
- yarn add @jdrks/ngx-deep-linking
You need to provide @Input and @Output for the fields you want to deep link.
- You must provide an @Input to initially populate the component field and change it if the url changes
- You may provide an @Output to change the url whenever that component output emits. Make sure to follow the naming convention for Angular two way data binding by appending 'Change' to the field name.
You need to provide a router config with the names of all fields you want to "deep link":
- See example below
- You can use the provided interface DeepLinkingRoute for a type safe configuration



import {DeepLinkingRoute, DeepLinkingWrapperComponent} from '@jdrks/ngx-deep-linking';
...

const routes: DeepLinkingRoute[] = [
  {
    path: 'books/:selectedBookId',
    component: DeepLinkingWrapperComponent,
    wrappedComponent: BookListComponent,
    deepLinking: {
      params: [{name: 'selectedBookId', type: 'number'}],
      queryParams: [{name: 'searchString', type: 'string'}],
    }
  }
];

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

The book list component could look like this:



@Component({
  templateUrl: 'book-list.component.html'
})
export class BookListComponent {

  private _selectedBookId: number = 0;

  @Output()
  private selectedBookIdChange: EventEmitter<number> = new EventEmitter<number>();

  @Input()
  get selectedBookId(): number {
    return this.selectedBookId;
  }

  set selectedBookId(value: number) {
    this.selectedBookId = value;
    this.selectedBookIdChange.next(bookId);
  }

  private _searchString = '';

  @Output()
  searchStringChange: EventEmitter<string> = new EventEmitter<string>();

  @Input()
  get searchString(): string {
    return this._searchString;
  }

  set searchString(value: string) {
    this._searchString = value;
    this.searchStringChange.next(value);
  }

  ...
}

So basically it's just like two-way data binding. The above implementation will automatically emit on the @Output fields when using the setters, but this is just convenience.

Features of ngx-deep-linking

Easily synchronize your component fields with the url by simple route configuration
Type safe configuration
Supports synchronizing fields of type number, string and even complex types as json
Supports lazy loading for Angular modules
Supports hash routing strategy

How does the library work under the hood?

The library wraps you component into the DeepLinkingWrapperComponent. The fields that should be "deep linked" are synced with the DeepLinkingWrapperComponent via "manual" two-way data binding. The wrapper reacts to changes on both url and wrapped component and updates vice versa.

Links

Github: https://github.com/Nas3nmann/ngx-deep-linking
npm: https://www.npmjs.com/package/@jdrks/ngx-deep-linking

I built yesno.

Julian Dierkes — Fri, 28 Aug 2020 16:23:10 +0000

Hi everyone,

while being quarantined for the last month i started a small project: yesno.

It is basically a webapp where you can anonymously ask yes/no question and everyone can anonymously answer them once before getting to see the yes/no statistics.
It has a new and a top (of the last 48h) questions section.

Technically I realized the Frontend Progressive Web App it with Angular and Ionic which was a great experience. The backend was written in Java with Spring Boot. Everything is deployed to heroku.

I'm really hoping for feedback and I am open for any questions. (Even non-yesno questions 😉 )

D is for debounceTime

Julian Dierkes — Tue, 18 Aug 2020 17:07:16 +0000

Welcome back! Today it is time for...

...two seconds later...

No NOW is time for...
The debounceTime operator!

What does it do?

It takes your source observable and starts a timer when a value is emitted. (The time is specified in milliseconds)
If no new value occurs before the timer finishes, debounceTime emits the value.
If a new value occurs nothing is emitted and the timer is reset and started again.

What kind of problems does this solve?

It is mostly used for performance improvements, e.g.

A line chart with panning and/or zooming functionality. You don't want to fetch new data on every pan/zoom interaction. Instead you want to fetch the data when the users has stopped scrolling or panning for a specified amount of time.
```
zoomChanged
    .pipe(debounceTime(200))
    .subscribe(newTimeWindow => fetchChartData(newTimeWindow))
```
Fetching data for an autocomplete input. You don't want to fetch the autocomplete data matching the current user input on each character the user enters. You want to fetch them when the users stops typing for a specified amount of time.
```
userInputChanged
    .pipe(debounceTime(200))
    .subscribe(userInput => fetchFilteredAutocompleteValues(userInput))
```

Pretty useful right?

Stay tuned for more RxJS glory!

Do we need JS naming conventions in TS?

Julian Dierkes — Tue, 11 Aug 2020 09:58:51 +0000

I tend to ignore JavaScript naming conventions that are based on visibility or type like "_aPrivateVariable" or "anObservable$", because they are already transparent through the use of Typescript.
How do you handle these naming conventions and why?

C is for combineLatest

Julian Dierkes — Sun, 09 Aug 2020 15:27:07 +0000

Let's check out the first function in this series: combineLatest.

Use this function whenever you are interested in the latest output of two or more Observables.

One can understand the behavior pretty good when looking at the marble diagram from the official documentation.

The upper observables emit the values in the marbles and are combined with combineLatest. As you can see it emits tha latest values of all its Observables whenever on of them emits. These values are then returned as array.

Enough theory! Show us the example!

Ok. I first used this operator in the following scenario:

We had a relational database with a many-to-many relationship and two different models that had to be consolidated and displayed in the UI written in Angular. Lets use Course and Student as examples here:

export interface Course {
  id: string;
  name: string;
  studentIds: string[];
}

export interface Student {
  id: string;
  name: string;
}

However the model we want to display should look like this:

interface CourseWithStudents {
  id: string;
  name: string;
  students: Student[];
}

So we need to merge both models into one view model.

Lets have a look on how to achieve this with the combineLatest operator.

We have two Angular services providing the data in form of an Observable, the CourseService and the StudentService.
I'm also simulating some http delay in the services using setTimeout().

export class CourseService {

  private _courses: Course[] = [
    {id: '1', name: 'German', studentIds: ['1', '3', '4']},
    {id: '2', name: 'Math', studentIds: ['2', '3', '5']},
    {id: '3', name: 'Biology', studentIds: ['1', '2']}
  ];
  courses: BehaviorSubject<Course[]> = new BehaviorSubject<Course[]>([]);

  constructor() {
    setTimeout(() => {
      this.courses.next(this._courses);
    }, 1000);
  }
}

export class StudentService {

  private _students: Student[] = [
    {id: '1', name: 'Johnny Rakete'},
    {id: '2', name: 'Melissa Woods'},
    {id: '3', name: 'Gordon Thorner'},
    {id: '4', name: 'Jamy Dormer'},
    {id: '5', name: 'Will Higgs'},
    {id: '6', name: 'Smantha Claire Restful'},
  ];
  students: BehaviorSubject<Student[]> = new BehaviorSubject<Student[]>([]);

  constructor() {
    setTimeout(() => {
      this.students.next(this._students);
    }, 2000);
  }
}

This is the code that combines both Observable results once any of them emits:

this.coursesWithStudents = combineLatest([this.courseService.courses, this.studentService.students])
  .pipe(
    tap(latestResults => {
      console.log('combineLatest emitted', latestResults);
    }),
    map(latestResults => {
      const [latestCourses, latestStudents] = latestResults;
      return latestCourses.map(course => ({
        id: course.id,
        name: course.name,
        students: latestStudents.filter(student => course.studentIds.includes(student.id))
      }));
    }));

This is basically just the combineLatest operator with some mapping logic attached. The whole code returns an Observable which we can consume e.g. with the async pipe directly in the template.

Lets see the output of the above code in three tables, one for courses, one for students and one for the combined result.

I've also integrated some console logging which pops up after the service timeouts emit. You can see that our merged Observable emits three times.

When the initial empty arrays are emitted by the BehaviorSubjects
When the courses array is emitted
When the students array is emitted

So we achieved what was desired. Every time the courses or students are updated the resulting table gets a fresh merged view model.

Thanks for reading! Feel free to check out the other articles of this series and stay tuned for the next ones.

B is for BehaviorSubject

Julian Dierkes — Sat, 08 Aug 2020 14:43:45 +0000

Well i think most of you have already heard about the BehaviorSubject. In case you didn't or want a quick refresh keep reading.
The BehaviorSubject, just like the normal Subject, emits values to its Observers, but there are two main differences:

It has an initial value
It emits its current value to new subscribers

What is it good for?

State management for example.

Here you mostly want an initial state, notifications for observers on changes and you also want to receive the current state on any later subscription.

Ok... That's all? This is your example?

Fine let's be more practical:

A data table. You want the data array that its based on to always be defined. Just use the BehaviorSubject with an initial value of [] and fetch or add some data whenever you feel like doing it. Even if the table subscribes after adding/fetching data the table will immediately receive the current state/data.
A toggle switch. It has an initial value of false so its deactivated. You want to notify several other components about changes. Even components created after the toggle (and therefore subscribing after the toggle state may have changed) will get the current value of the BehaviorSubject.

A is for AsyncSubject

Julian Dierkes — Sat, 08 Aug 2020 14:06:04 +0000

The AsyncSubject is a lesser known sub class of Subject, that emits only its last value to its Observers once (and only if) it completes.

But isn't that the same thing as using a Subject and the last operator?

Nearly, but the AsyncSubject is designed for multicast usage (multiple Observers) and the behavior differs for Observers that subscribe after completion.
The value is also emitted to Observers subscribing after the AsyncSubject has already completed, which does not happen when using a simple Subject.

When would I need such a Subject?

For example this could be handy for implementing something containing HTTP requests. Knowing that http request will only have a single result it totally makes sense to use an AsyncSubject because:

It will only emit a single value
It completes, so there is no need for the Observers to unsubscribe
Other Observers can even subscribe after the request has finished

Provider Scopes in Angular

Julian Dierkes — Sat, 04 Jul 2020 13:31:51 +0000

Angular Level:

Angular's modular system provides you with the ability to create Components and Services.
While Components should be focused on the view, meaning the html template, a Service should be used for the application logic. While, from my experience, they are mostly used for HTTP requests, Services mayfulfill other purposes as logging or validation. Many Services will be reused throughout one application.

When reusing Services, it is important to think about the scope, in which you want to provide it.

Angular basically offers three scopes:

Root Scope
Module Scope
Component Scope

The Root Scope

The root scope is the most commonly used scope for providing Services as it is also the default scope when creating a Service via Angular CLI.

@Injectable({
  providedIn: 'root'
})
export class ExampleService {}

The default providedIn argument in the CLI generated Service above means that the Service will be provided in the application root, the AppModule. Therefore the Service will be a singleton, meaning that there will be only one instance of this Service even if it is injected in multiple Modules and used in multiple Components or Directives.

Hint: Using the providedIn argument in @Injectable can also optimize bundle sizes if a service isn't used, which is especially useful for writing libraries. More info in the Angular Docs

The Module Scope

The same way we can provide the Service in Module scope:

@Injectable({
  providedIn: 'ExampleModule'
})
export class ExampleService {}

But what if we don't want to share the service between modules?
We can then (instead of provideIn) use the providers array in the corresponding @NgModule:

@NgModule({
  ...
  providers: [
    ExampleService
  ]
})
export class ExampleModule {}

This way an instance of the service is created for the Module. If the service is added to the providers array of multiple Modules, each Module gets its own Service instance.

The Component Scope

We can also create an individual Service instance for a Component by using the Component scope:

@Component({
  ...
  providers: [ExampleService]
})
export class ExampleComponent{}

Let's see this in action

Let's get our hands dirty and create an example application using Module Scope and Component Scope.

I've used the Angular CLI to create a project with the following structure:

There is only one Service, which is located in the SharedModule:

@Injectable()
export class ExampleService {

  name = "Frank";

  constructor() {
  }
}

This Module and therefore the Service is used two other modules which both are then imported in the AppModule.

The ComponentScopeModule which uses the Component Scope and consists of two components

ExampleComponent1 which provides an input for the service's property name

@Component({
  selector: 'component-scope-example1',
  template: `<input [(ngModel)]="service.name">`,
  providers: [ExampleService]
})
export class Example1Component {

  constructor(readonly service: ExampleService) {
  }
}

ExampleComponent2 which just displays the service's property name

@Component({
  selector: 'component-scope-example2',
  template: `<p>{{service.name}}</p>`,
  providers: [ExampleService]
})
export class Example2Component {

  constructor(readonly service: ExampleService) {
  }
}

The ModuleScopeModule which uses the Module Scope and consists of two similar components.
The difference is, that the Components don't use the providers array. Instead the Service is provided
in the Module:

@NgModule({
  declarations: [Example1Component, Example2Component],
  imports: [
    CommonModule,
    SharedModule,
    FormsModule
  ],
  exports: [
    Example1Component,
    Example2Component
  ],
  providers: [
    ExampleService     <--- it's provided here instead
  ]
})
export class ModuleScopeModule {
}

All four Components are then displayed using the AppComponent:

<div>
  <h1>Module Scoped</h1>
  <module-scope-example1></module-scope-example1>
  <module-scope-example2></module-scope-example2>
</div>
<div>
  <h1>Component Scoped</h1>
  <component-scope-example1></component-scope-example1>
  <component-scope-example2></component-scope-example2>
</div>

And finally this is what we get:

We can see that in the "Module Scoped" section both components use the same service and therefore the input of the first component changes the output of the second component.
In the "Component Scoped" section this does not work as there are two service instances created,
one for each component.

Thanks for reading!

Cheers Julian

Where/How do you get your ideas?

Julian Dierkes — Sat, 04 Jul 2020 10:49:47 +0000

Hi @all,
I currently have a lot of time to learn and try new things and would like to use all that new stuff on real world appications. But I am struggling with ideas for libraries/apps that really bring value to someone.
How do you come up with ideas for such stuff?

I'm thankful for any input on this topic.

Cheers Julian

Two Ways of Using Angular Services With the HttpClient

Julian Dierkes — Thu, 02 Jul 2020 16:39:35 +0000

Angular Level:

The Old Fashioned Way: The 'Pull' Approach

When starting to build an Angular app you most likely come to the point where you need some kind of HTTP communication.
I guess every intermediate Angular user has used the http client before.
Most likely it was wrapped in an Angular service.
E.g. a service for a shopping list app could look like this:

@Injectable({
  providedIn: 'root'
})
export class ShoppingListPullService {

  ITEMS_URL = 'assets/items.json';

  constructor(private httpClient: HttpClient) {
  }

  getItems(): Observable<ShoppingItem[]> {
    return this.httpClient.get<ShoppingItem[]>(this.ITEMS_URL);
  }
}

A component then gets the shopping items via a simple method call, stores them and can display them like this:

@Component({
  selector: 'app-pull',
  template: `
      <div *ngFor="let user of items">
          - {{user.quantity}} {{user.name}}
      </div>
  `
})
export class PullComponent implements OnInit {

  items: ShoppingItem[];

  constructor(private readonly shoppingListService: ShoppingListPullService) {
  }

  ngOnInit(): void {
    this.shoppingListService.getItems()
      .subscribe(items => this.items = items);
  }
}

Note that we don't need to unsubscribe here, as the angular HttpClient handles this for us.
If we had another kind of Observable here, we would also need to unsubscribe.

Let's call this approach the "Pull Approach", because it pulls the data from the service and the component is responsible for holding the state (in this case the array of shopping items).
After any possible change of the items a refetch must be done including the corresponding subscribe block.

This approach is nice and simple, but may not be suitable if multiple components use the service and all of them should share one consistent state.
E.g. imagine you have a component for listing the items and one component for adding new items.
Both components need control of the list.

Observable Data Service: The 'Push' Approach

Here an "Observable Data Service" or "Service With a Subject" is much more convenient.
It may look like this:

@Injectable({
  providedIn: 'root'
})
export class ShoppingListPushService {

  ITEMS_URL = '/assets/items.json';

  private readonly items$: BehaviorSubject<ShoppingItem[]> = new BehaviorSubject<ShoppingItem[]>([]);

  constructor(private httpClient: HttpClient) {
  }

  fetchList() {
    this.httpClient.get<ShoppingItem[]>(this.ITEMS_URL)
      .subscribe(receivedItems => this.items$.next(receivedItems));
  }

  get items(): Observable<ShoppingItem[]> {
    return this.items$.asObservable();
  }
}

Let's have a look on how this works:

The fetchList method executes an HTTP request.
After it returned the items successfully they are published to the BehaviourSubject items$, which means that anyone subscribed to this subject will get that new array of items.
This Subject is made public in the form of an Observable by the get method below so nothing can be published from outside of the service.

This kind of service can easily be used with the Angular async pipe.
No need to subscribe to or unsubscribe from anything.

@Component({
  selector: 'app-push',
  template: `
      <div *ngFor="let item of shoppingListService.items | async">
          - {{item.quantity}} {{item.name}}
      </div>
  `
})
export class PushComponent implements OnInit {

  constructor(readonly shoppingListService: ShoppingListPushService) {
  }

  ngOnInit(): void {
    this.shoppingListService.fetchList();
  }
}

Only thing left to do programmatically in the list component is to trigger the data fetch.

So let's again imagine a second component using this service to add items to the shopping list.
After adding an item the component may easily trigger the fetchList() method and cause an update of the item list in the other component.

Pretty easy, huh?