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.

Sign up for GitHub

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

Jump to bottom

[RFC] Declarative App / Page Templates #299

Closed
1 of 5 tasks
thescientist13 opened this issue Mar 10, 2020 · 2 comments
Closed
1 of 5 tasks

[RFC] Declarative App / Page Templates #299

thescientist13 opened this issue Mar 10, 2020 · 2 comments
Assignees
@thescientist13
Labels
invalid This doesn't seem right question Further information is requested RFC Proposal and changes to workflows, architecture, APIs, etc
Milestone
1.0

Comments

@thescientist13
Copy link
Member

thescientist13 commented Mar 10, 2020 •
edited
Loading

Type of Change

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

Summary

In the context of working on #128 , I got to thinking about the kinds of patterns and approaches we can / should support for injecting dynamic data into the page.

Generally, there are two approaches that can be used:
Imperative (current pattern)

connectedCallback() {
  super.connectedCallback();

  const head = document.head;
  const titleElement = head.getElementsByTagName('title')[0];

  titleElement.innerHTML = title;
}

Declarative (current pattern)

render() {
  const { meta } = this;

  return html`
    ${meta.map((item) => {
      return html`
        <meta ${...item}/>
      `;
     })}
  `;
}

Details

There are interesting pros / cons to both approaches. Personally, declarative feels more ergonomic and seems to fit the tagged template literal driven approach of JavaScript

  • The declarative approach would likely require re-structuring our app-template.js and page-template.js since we would need to do this in the <head> of page. Should probably try and coordinate with changes in Route Based Code Splitting #265
  • A downside of the imperative approach is that it requires relying on async DOM updates
  • Imperative is not necessarily idempotent, especially if using DOM methods like appendChild. Order / sequence / duplication becomes a real concern.
  • In theory, with being able to override xxx-template.js files, user could easily do one instead of the other
  • This might get us to want to think (possibly) how scripts / styles / etc are passed in via greenwood.config.js. Maybe a just an object like this instead 
     {
   head: {
     scripts: [{
       src: '',
       attr: {}
     }],
     style: [{
        href: '',
        attr: {}
     }],
     meta: [{
        /* same as currently */
     }]
   }
}
@thescientist13 thescientist13 added the RFC Proposal and changes to workflows, architecture, APIs, etc label Mar 10, 2020
@thescientist13 thescientist13 added this to the MVP milestone Mar 10, 2020
@thescientist13 thescientist13 self-assigned this Mar 10, 2020
@thescientist13 thescientist13 mentioned this issue Mar 10, 2020
Merged
4 tasks
This was referenced Mar 18, 2020
Closed
Closed
@thescientist13 thescientist13 mentioned this issue Sep 22, 2020
Closed
53 tasks
@thescientist13 thescientist13 added the invalid This doesn't seem right label Nov 7, 2020
@thescientist13
Copy link
Member Author

Not sure if this still applies?

@thescientist13 thescientist13 added question Further information is requested and removed invalid This doesn't seem right labels Nov 8, 2020
@thescientist13
Copy link
Member Author

well, now that everything is based off HTML for our templates, looks like we "get" this one for free.

@thescientist13 thescientist13 added the invalid This doesn't seem right label Mar 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@thescientist13 thescientist13

Labels
invalid This doesn't seem right question Further information is requested RFC Proposal and changes to workflows, architecture, APIs, etc
Projects
None yet
Milestone
1.0
Development

No branches or pull requests
1 participant
@thescientist13