Component Service Interaction

[snewcomer]

In order to enable a more flexible approach, we could potentially define a restricted set of meta keys that are emitted to the template...that allows the user to set on the head-data service from anywhere...like a component for example.

// component.js

this.headData.set('descriptionContent', 'My description');

So something like description would be an array of loc keys

  descriptionContent: '',
  description: computed('routeName', 'descriptionContent', function() {...});

So in the end we have a route approach + a set approach + default config approach. What do you think?

[RobbieTheWagner]

You can do this already, all the meta is stored in the head data service, so this.headData.set('descriptionContent', 'My description'); will work everywhere.

[snewcomer]

Oh right but we need to be able to emit to a template, right? So I would imagine this would have to be incorporated into the description computed. So in the end, the description computed would be responsible for either the route approach setting the descriptionContentordefault config` approach.

[RobbieTheWagner]

You can use your own head.hbs and define whatever extra properties you want on the head-data service, to make things completely customizable. I'm open to ways of streamlining the API, but this should all theoretically be possible now.

[snewcomer]

I guess the goal is to make the service workable for routes and for component interactions so that, for example description just works out of the box in either case w/o having to use my own head.hbs. Right now it only works for routes. Lmk if I am missing something....

[RobbieTheWagner]

Ah okay, so you are saying we should find a common configuration that would work for any spot in the app, and update the computeds, rather that making all the computeds look at the current route? If there is a seamless way to do this, that sounds great to me. It would be nice to override the same way everywhere.