-
Notifications
You must be signed in to change notification settings - Fork 10
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
Adding dynamic, configurable, meta component, to page template #73
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's try using HtmlWebpackPlugin
to template in the <meta>
tags by fleshing out all the values in the graph, as it could be an easier way in then a new JS file.
Could also open up possibilities for more ways to inject additional HTML from us or users, like Analytics code.
…ask/fix-issue-5-metadata
We cannot simply do HTMLreplacement, because that would work for only a single html file, whereas we would have many html files for each route, each with dynamic meta data. We cannot do this in webpack, I should have realized this earlier when we discussed it. That's why I originally had a component handle setting the meta data as it does in helmet. The alternative is to have it do it during serialization, by modifying the dom with jsdom. That unfortunately will only run in production, and therefore I think that's not feasible. People need that meta in development, which doesn't run the serialization on dev build. Back to square one. |
We've been avoiding having extra components affiliated with the default template, and now we have little choice but to add a meta component. I also prefer the default template to look a little bit better than simply hello world anyway. So this problem, with the NormalModuleReplacementPlugin logic with |
…rehydration, update webpack ModuleReplacement exception
…rehydration, update webpack ModuleReplacement exception, update templates
For now, I've hard coded an exception for any imports within cli/templates to be ignored by moduleReplacementPlugin. It's not the cleanest solution, but its pretty simple. It only works with absolute paths, residing in a directory within cli/templates such as |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this PR will need a little TLC post testing refactor PR. But also a good opportunity to add some new cases! 😁
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some interesting things happening here in this PR, seeing some interesting ideas / paths / options for extending Greenwood going forward, taking a lot of notes here 🤓
Left some comments / feedback, but this is looking really good so far!
* } | ||
*/ | ||
|
||
class meta extends LitElement { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this could be a good candidate as a POC for our "first" (second) package in our (pending) monorepo in terms of coming up with an initial approach for how consumers can extend Greenwood. (markup anyway)
Maybe some sort of configuration where users can provide these placeholder (or Greenwood can provide standard ones, like META
) and then we can have plugins for each of these "hooks".
I think it will be good to consider this to help avoid a giant configuration file. Even something like meta could become complex and warrant its own standalone package / API.
My guess is users will include / configure plugins like this and pass it into our configuration.
Just thinking out load, but seems like we could probably get a basic RFC drummed up from this idea for a post Sprint 2 enhancement (basically a "use the platform" version of react-helmet?. 🤔 💡
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about this as well, I was tempted to add this to my evergreen web component library That way, there would be no issue with importing it.
@@ -0,0 +1,167 @@ | |||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we break this out into two cases
- build.config.title
- build.config.meta
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we also get two additional cases
- test empty / default meta values (or maybe update smoke test to test no meta data added?). maybe do an array check?
- add error handling case for title
@@ -52,7 +52,7 @@ describe('Build Greenwood With: ', function() { | |||
it('should have a <title> tag in the <head>', function() { | |||
const title = dom.window.document.querySelector('head title').textContent; | |||
|
|||
expect(title).to.be.equal('My App'); | |||
expect(title).to.be.equal('Greenwood App'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I forget, I think we talked about this on the weekly call, by why do we need to change other cases here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea that's the default title within the config.js. So if no title is added to the greenwood.config.js, it will use that one.
@hutchgrant 176 passing (2m)
1 failing
1) Build Greenwood With:
Default Greenwood Configuration and Workspace w/Custom Style Page Template
Running Smoke Tests: Default Greenwood Configuration and Workspace w/Custom Style Page Template
Index (Home) page
should have a <title> tag in the <head>:
AssertionError: expected 'My App' to equal 'Greenwood App'
+ expected - actual
-My App
+Greenwood App
at Context.<anonymous> (test/cli/smoke-test.js:91:29) |
no its not the text, its the fact the template doesn't have the hooks for the meta component! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Phew! 0.2.0, what a ride! 🎢
Related Issue
Resolves #5
Summary of Changes
og:url
andog:title
meta are added by defaultgreenwood.config.js
doubled the time for the tests because my laptop would fail with 15000
every page-template which intends to use meta needs to include
METAIMPORT
andMETADATA
at top, as well asMETAELEMENT
somewhere in the render. Like this:when built, the scaffold.js will replace those variables like so:
Problems
* webpack import path adjustment has a problem related to the import of the meta component. I'd prefer users not have to supply one when using custom page templates. Also absolute paths are bugged, had to hardcode a relative one. Will need to work on this issue* for now need to inclue meta.js within all user workspace component folders* needs testsTo be clear this is a good base to begin with. The meta component maybe should also include the window.location as og:url by default.TODO
Another day, we may want to enable additional front-matter meta overrides within graph.js