Integration with Angular's title system

[davidlj95]

Could be nice to take into account Angular built-in tools for setting titles:

• Route.title
• TitleStrategy

Actually, hasn't been tested what happens if using those and the library too. Who will win? 🏁

[davidlj95]

After taking a look at the interface, seems the method that is responsible for building the title for the page is:

buildTitle(snapshot: RouterStateSnapshot): string | undefined

However, in this case, we can provide the user with the title they provided in their metadata values JSON object. So implementing that interface would be doing the work the library is also doing to resolve metadata values from the current route.

Ideally to format the title according to some pattern or something, the user would receive the title received as part of metadata resolution and return the formatted title. So seems that interface is not the ideal one to implement.

[davidlj95]

Then, after trying what happens when library is installed, a title is specified in route data and a Route.title is specified too. And seems Angular wins. Angular's Route.title is set in the page title despite the library doing the same too.

If the library has to set other titles like Open Graph's title, it does so. Therefore if using Angular's title and library's title Angular's one will win. This is using the DefaultTitleStrategy. That indeed hasn't been specified. Testing this with a fresh Angular v19.0.0 app.

[davidlj95]

If setting title by calling the service on the component's ngOnInit, the library wins the race. And the library title is set.

[davidlj95]

Will add some console.logs so that the whole order is clear. To do so, will provide a custom title strategy that logs when called. Here's the order:

ngx-meta/routing/listener: ngxMetaService.set() // lib's router listener calling service to set metadata
ngx-meta/standard/title: setting title // lib's title manager setting page title
TitleStrategy.updateTitle // title strategy's `updateTitle` called
HomeComponent.ngOnInit: ngxMetaService.set() // `ngOnInit` called, which calls service to set metadata

Some interesting finding is that neither buildTitle nor getResolvedTitleForRoute methods are called. Just updateTitle is called. Why is that? After looking at Angular's code, seems that other methods are intended to be helpers to updateTitle. But if updateTitle doesn't call them, they aren't called.

For instance, check the Angular.dev's title strategy

@Injectable({providedIn: 'root'})
export class ADevTitleStrategy extends TitleStrategy {
  // ...
  override updateTitle(routerState: RouterStateSnapshot) {
    const title = this.buildTitle(routerState);

    if (title !== undefined) {
      this.title.setTitle(title);
    }
  }
}

It is inside updateTitle implementation that buildTitle is called. And no need to go so far, DefaultTitleStrategy does the same. Or in common routing tasks guide in docs

[davidlj95]

It might be interesting to integrate with Angular's title system, as the common routing tasks guide says:

Each page in your application should have a unique title so that they can be identified in the browser history. source

So very probably that's the title used when replacing browser history with History API. Hence integrating with this system would be great so that browser history and actual title history is aligned.

[davidlj95]

For instance, if setting the title using Angular system, library's route + service call on ngOnInit, then library wins.

However, in theory the title in history should be Angular because it's the one calling history API. However, browser seems to override that. But if using Angular system + library's route, Angular system wins.

In theory, browser history should display both titles as the titles being set with Angular system given that's the title used when calling history API. However, seems that browse history respects the final title:

Home page is set with Angular + lib route + lib service call on ngOnInit
Non home page is set with Angular + lib route

So the title that ends up in each case is actually the title appearing in the browser history. At least in Chrome when viewing history. Not Angular title as one could expect.

[davidlj95]

Hmmm seems it's actually unused! When using history.pushState to tell the browser we're navigating somewhere, the title parameter isn't actually used as stated in MDN Docs about the API

unused
This parameter exists for historical reasons, and cannot be omitted; passing an empty string is safe against future changes to the method

Going a bit down the rabbit hole, found nothing in the HTML spec. However, found some info in the

• PR updating HTML spec
• Issue about title not being used by implementations
• Issue about no way of retrieving set title
• Interview with who came up with it. Saying it was introduced in an early design and when wanting to change it, everyone was using it already, so couldn't do so as would be a breaking change

Main pieces:

It seems we could reduce confusion in the spec by saying something along the lines of: The title provided in pushState and replaceState is only associated with the current history entry, not with the current document or browsing context. Providing it will not alter document.title, nor will the user agent use a history state's title as a substitute for document.title in its user interface as a label for a given browsing context. The user agent may however use the title as a label for a history entry in history navigation user interfaces. source

Even the features that are designed in public with wide review end up implemented and used before they’re “done”, and once they’re used they can’t be changed — which leads to APIs that make no sense, like pushState(), which has a required argument that is ignored.

The hardest part of this is that we can’t tell if something we’ve designed is any good without testing it in real world sites, and by the time it’s been properly tested, it’s too late to change it. pushState() happened like this (where we learnt that the second of the three arguments should be dropped only after there were already pages depending on using the first and third arguments) [...] source

[davidlj95]

Indeed Angular seems to pass empty string when calling history APIs like pushState:

• https://github.com/angular/angular/blob/e294ca8e09429e4ebc5967d1d1f044aac07f7cc3/packages/common/upgrade/src/location_shim.ts#L286-L291
• https://github.com/angular/angular/blob/e294ca8e09429e4ebc5967d1d1f044aac07f7cc3/packages/common/src/location/location.ts#L167

[davidlj95]

And never has. Going back in time, seems that second argument was never provided. (also first wasn't):

angular/angular#1631

[davidlj95]

Angular title system was introduced here:
https://github.com/angular/angular/pull/43307/files#diff-cb9e7870dcdd28eeeae7ad541fd460d8c950d908fc65de921e187e86a0997962
angular/angular@910de8b

In v14, not so long ago! Jan 2022

Comes from this issue:
angular/angular#7630

In there someone already commented about title not having effect on pushState

[davidlj95]

See also the design doc
https://docs.google.com/document/d/1ZqMp8sT46koXUF-uZd6PZ3CzNhpzcRyOAjcVdhyYarE/edit?usp=sharing

[davidlj95]

It was introduced as it's important to define a unique page title for a11y purposes
https://www.w3.org/WAI/WCAG21/Understanding/page-titled

[davidlj95]

Sooo to recap:

• Route.title is used by TitleStrategy to fetch the title for a page. Specifically in getResolvedTitleForRoute. Which is used by buildTitle. Which may be used by updateTitle to actually update the title. DefaultTitleStrategy does that.
• If providing Angular title + lib title on route data, Angular title is set
• If providing Angular title + lib title on ngOnInit or later, lib title is set

Would be great to integrate with Angular title system. As:

• Users may be already providing titles that way. Hence using the library will require less migration.
• Will avoid confusion about why sometimes lib title is set, but others Angular title is set.
• Can bring best practices from Angular into here. Like using Resolvers.
  • Indeed, I'm thinking that there should be a cookbook about that in docs. Given that we are calling meta service setter in NavigationEnd, which is after ResolveEnd. Hence resolved data is already there -> docs: add cookbook about using async metadata values thanks to resolvers #1054

Btw also found that there's an issue from an Angular's dev rel about adding something like title system but for metadata. Tiruriii angular/angular#44928

Someone raised a PR, but given no design had been discussed, it was closed. Also, the PR didn't contemplate cases like:

• Removing metadata when navigating (as mentioned in there)
• Adding many meta elements of same kind (it uses meta.updateTag, which replaces elements with same name or property attr)
  ...