Add ember-page-title to app default blueprint

[KamiKillertO]

Rendered

[kellyselden]

Should we audit the API of the addon as part of this effort?

[NullVoxPopuli]

Should we audit the API of the addon as part of this effort?

@kellyselden I think so. There are certain capabilities I'd want to make sure are present, and I'd want to make sure that any addon we add "feels nice" to use

---

I have no experience with this addon, and haven't used anything other than custom title manipulation, so predisposition-wise, I'm starting from scratch. :D

Left some questions

[NullVoxPopuli]

does the addon maintain a history of the titles?

Like, if I were to do a bunch of navigations where some, but not all page-title invocations have replace=true, does the title always reflect what is rendered?

Does that mean that the page title is dependent on render order?

What happens if I do?

{{#each this.breadcrumbs |breadcrumb|}}
  {{page-title breadcrumb.name}}
{{/each}} 

[KamiKillertO]

I'm not sure, I'll make a dummy app to test ^^

[raido]

I'll add nested route + breadcrumbs test case to ember-page-title and we'll find out.

[btecu]

Why ember-page-title and not something like https://github.com/mike-north/ember-cli-document-title-northm (fork of https://github.com/kimroen/ember-cli-document-title)?

[NullVoxPopuli]

Why ember-page-title and not something like https://github.com/mike-north/ember-cli-document-title-northm (fork of https://github.com/kimroen/ember-cli-document-title)?

💯

While I have no allegiance to any of these addons, I think in the alternatives / prior art and/or detailed design section, there should be some comparison between them? What makes one addon objectively better than the others and worth including by default?

[kellyselden]

Yeah I think we should be committed to whatever addon and API we choose. It has to make sense, and not just come along because the addon is popular. For instance. I see that the way to configure the addon is a key on ENV in config/environment.js. Is that still the canonical way to configure addons in an Octane world? The answer is probably yes, but I just want to make sure.

[KamiKillertO]

The first intent of the a11y strike team was to create an addon with the features of ember-page-title and ember-document-title. But, according to @MelSumner and a discussion she had with Yehuda (if remember correctly), ember-page-title is more aligned with the direction ember and front end frameworks are taking. Maybe @MelSumner can confirm 😊

[MelSumner]

The first intent of the a11y strike team was to create an addon with the features of ember-page-title and ember-document-title. But, according to @MelSumner and a discussion she had with Yehuda (if remember correctly), ember-page-title is more aligned with the direction ember and front end frameworks are taking. Maybe @MelSumner can confirm 😊

Yes that’s correct! We felt ember-page-title was the most aligned with the current and future direction of the framework (a template-based solution).

[MelSumner]

@rwjblue reminder to file the relevant issues on the addon so we can move to FCP this RFC. 👍

[knownasilya]

@rwjblue are there any breaking changes required? Was planning on releasing a new major version this week.

[simonihmig]

Yes that’s correct! We felt ember-page-title was the most aligned with the current and future direction of the framework (a template-based solution).

While I can relate to that, I think the RFC should explain that in some detail. Like there are a couple of other similar addons - which IIRC follow a route-based rather than template based API - and why do we pick this one and not one of the others?

Which brings me to another topic: meta tags. While this RFCs only mentions a11y concerns as a motivation - which is legit - another one is SEO, especially when used with FastBoot. But when thinking of SEO, you also want to account for proper meta tags.

While this does not necessarily be tackled within the same RFC, I think we should have at least a broad idea about how to extend support to meta tags. So there a couple of addons (e.g. ember-cli-meta-tags, ember-meta) for this, which

• are also based on ember-cli-head
• follow a different route-based API
• also allow to set the title tag ⚠️

So when endorsing one addon in such a massive way by making it a default one, we should make sure there is a viable way to also support meta tags, that

• follows the same API philosophy (template vs. route)
• does not cause conflicts or overlapping concerns
• and as such guarantees a pleasant DX

Or at least we should make sure there are no reasons to later revert our decisions here because of this.

Another thing: what does making a "user-land" addon a default one mean in terms of maintenance guarantees? I am in no way suggesting this addon is not well maintained (frankly I have no idea, I haven't used it before), but the addon is part of the addopted-ember-addons because of lack of maintenance in the past I assume, so does adoptig this RFC basically mean this addons gets a maintenance guarantee from some official Ember team (core, cli?), in case current maintainers are not able to provide that anymore? If so, does it make sense to transfer the addon to the @emberjs org, to signal that stability guarantee to users?

[KamiKillertO]

While I can relate to that, I think the RFC should explain that in some detail. Like there are a couple of other similar addons - which IIRC follow a route-based rather than template based API - and why do we pick this one and not one of the others?

It's a good idea, I'm gonna add a small explanation 👍 .

Another thing: what does making a "user-land" addon a default one mean in terms of maintenance guarantees? I am in no way suggesting this addon is not well maintained (frankly I have no idea, I haven't used it before), but the addon is part of the addopted-ember-addons because of lack of maintenance in the past I assume, so does adopting this RFC basically mean this addons gets a maintenance guarantee from some official Ember team (core, cli?), in case current maintainers are not able to provide that anymore? If so, does it make sense to transfer the addon to the @emberjs org, to signal that stability guarantee to users?

In the RFC, it's indicated that this addon should be transferred to the Ember CLI org. It's true that making an addon part of the default blueprint involves that the official Ember team will have to maintain it somehow and we should be very careful about that. This question was raised while working on the RFC 638 and now the RFC clearly indicates that before adding any new option using an external addon, we should evaluate the maintenance cost that might come with.

[knownasilya]

I'm interested in the meta tags discussion, and am highly aware of the importance there as well. We just removed ember-cli-head from ember-page-title, so the meta support is no longer included because of that dependency. I think that area is worth discussing but unsure if it should be in this PR. Maybe something template based as well.

{{page-meta (hash og:title='Test')}}

Not sure we can do something like that with special characters. Will have to see if (hash 'og:title'='Test') works.

---

Edit, looks like it works as (hash og:title='Test') https://ember-twiddle.com/bac18e42d25f5b6896e15cdcb6eb20b2?openFiles=templates.application%5C.hbs%2C

[gossi]

I agree with @simonihmig here. There is more than just <title>. I can relate to all his points. Indeed I found an old gist I put together that explains the whole problem around this: https://gist.github.com/gossi/c3d6fded03be001d8b9763a8219b0a5e It's from almost one year ago. Ignore the code, take the idea.

Actually, what I would expect from ember would be an API that the various addons can connect to. So ember is reigning <head> (or parts of it) and provides an API to that. Addons will use this API to exchange information. I as a consumer can choose an addon that provides the API I am looking for - not the one ember picks for me. For example:

I will write myself a decorator that I put on my routes, to control the title and it's hierarchy/information architecture of my site and another breadcrumb component (which I installed as an addon) that will use that generated data to control the breadcrumbs. The data lives in the "central head content repository".

[knownasilya]

I think we can have both, an official service and helpers that let you change that without having to install addons. For accessibility it should be included out of the box, because otherwise it's not done, especially by junior devs. I could even see a template linting rule that knows if you are at a route template and suggests adding a title, but that would be difficult if they had to go down a rabbit hole of how to setup a title with a service and where does it go, etc.

[MelSumner]

@KamiKillertO now that ember-page-title has a new release, I think we can update this RFC to reflect that, and work on getting this RFC shipped. 👍🏻

[KamiKillertO]

Thanks @MelSumner 👍 , I've already updated the RFC to reflect ember-page-title changes

[MelSumner]

We have discussed this in today's Framework Core Team meeting, and decided to move this RFC to Final Comment Period.

[hergaiety]

Just voicing support for this RFC and bringing the addon into the core app. I'm glad to see page titles will be less of an afterthought in the apps I work on every day and I'll no longer need to make a case to include another addon, as that case has already been made here! Great work to everyone involved 🎉

[raido]

This seems to be still relevant issue - ember-cli/ember-page-title#90 from accessibility perspective?

[KamiKillertO]

I don't think 🤔.
Screen readers don't announce page title updates when there are no actual page navigations (navigation to a new HTML page), which is the case with ember applications (because of the router). This is why the addon a11y-announcer exist.

[rwjblue]

Lets do it!