Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

<title></title> element is static #128

Closed
1 of 5 tasks
hutchgrant opened this issue Jul 24, 2019 · 2 comments
Closed
1 of 5 tasks

<title></title> element is static #128

hutchgrant opened this issue Jul 24, 2019 · 2 comments
Assignees
Labels
Content as Data enhancement Improve something existing (e.g. no docs, new APIs, etc) v0.5.0 Data w/ GraphQL
Milestone

Comments

@hutchgrant
Copy link
Member

hutchgrant commented Jul 24, 2019

Type of Change

  • New Feature Request
  • Documentation / Website
  • Improvement / Suggestion
  • Bug
  • Other (please clarify below)

Summary

The <title></title> element is static and should potentially change on each page.

We should also remove <title> from index.html

Details

In our meta component we're using a static title for each page, but perhaps we want the title to be static + a dynamic page name. This would require using front-matter variables from each markdown page, and somehow through our API for other non-markdown pages to alter titles for each page's header.

e.g. Greenwood | Getting Started

edit:

Also og:title and og:description are also static. I'd prefer them to be dynamic for each page as well.

@thescientist13 thescientist13 added chore unit testing, maintenance, etc enhancement Improve something existing (e.g. no docs, new APIs, etc) and removed chore unit testing, maintenance, etc labels Jul 24, 2019
@thescientist13
Copy link
Member

thescientist13 commented Jul 27, 2019

I think this a great idea, and thinking about it for a bit helped me realize that if we can pull off #115 , then user's will be able to do whatever they want, which could yield a much better API / developer experience, and less overhead for Greenwood, all while still using Web Components!

By being able to pull data from Greenwood, the <eve-meta> can simply take attributes / prop derived at build time, which will continue to reduce any particular business logic within the component itself.

For example, building off this snippet, developers in their page templates could get page specific meta data and / or front matter, and just customize metadata as needed, and pass it down to <eve-meta>.

In theory, in this way, Greenwood doesn't even have to care about meta in the config at all, it could / would just be a page-template.js concern only? 🤔

import { config, graph } from '@greenwood';
import { html, LitElement } from 'lit-element';

let metadata = config.meta.slice(0);

metadata.map((meta) => {
  if (meta.property === 'og:title') {
    meta.value = `${meta.value} | ${graph.page.name}`
  }

  return meta;
});


class PageComponent extends LitElement {
  render() {
    return html`
       <eve-meta .attributes=${metadata}>
        MYROUTES
        <lit-route><h1>404 Not found</h1></lit-route>
    `;
  }
}

customElements.define('eve-page', PageComponent);

Although maybe it would be more practical for <eve-meta> to take an object instead of an array? That way customizing things would be a lot simpler then trying to filter an array for og:title.

Example:

let metadata = config.meta;

metadata['og:title'] = `${metadata['og:title'].value} | ${graph.page.name}`;
// others here, or a loop, if you still want

@hutchgrant
Copy link
Member Author

hutchgrant commented Jul 28, 2019

I think this is a good starting point for getting the build time injection working. My thoughts are this is why gatsby writes caches to json files, that way when webpack compiles our components, they import the graph and use the data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Content as Data enhancement Improve something existing (e.g. no docs, new APIs, etc) v0.5.0 Data w/ GraphQL
Projects
None yet
Development

No branches or pull requests

2 participants