-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
chore(rebuild): populate page titles #2040
Conversation
src/server.jsx
Outdated
<html> | ||
<head> | ||
<meta charSet="UTF-8" /> | ||
<meta charset='utf-8' /> |
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.
these should be doublequotes
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 agree. And in general, we should avoid misc formatting changes like line 26, lines 51 - 53, etc. I understand some of my stylistic choices might be a little different but I'd rather us fix this with something like prettier instead of changing things back and forth due to personal preference. Also, these little things create a lot of noise on PR like this, meaning it's hard to tell what's related to the title population and what are just misc formatting things.
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.
@skipjack Yeah, another prettier change, submit a PR to add it to the repo. Sorry for the noise.
It works locally but i have an issue with title containing empty html comment notation, if you do |
@EugeneHlushko Nope, debugged it for 1 hour when I did it, no idea why does it happen. My best guess is that React think there is an space there, but not sure. |
webpack.prod.js
Outdated
@@ -7,6 +7,17 @@ const SSGPlugin = require('static-site-generator-webpack-plugin'); | |||
|
|||
// Load Common Configuration | |||
const common = require('./webpack.common.js'); | |||
const Content = require('./src/_content.json'); | |||
|
|||
const paths = Content.children.reduce((paths, page) => { |
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 can also be done in the server file, but I think it is better here.
webpack.prod.js
Outdated
@@ -27,7 +38,8 @@ module.exports = env => [ | |||
}, | |||
plugins: [ | |||
new SSGPlugin({ | |||
crawl: true, | |||
paths: Object.keys(paths), |
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.
@skipjack I really tried to use crawl
option, but it fails to crawl entire configuration
content, because that URL is missing from the homepage.
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.
On the readme of static-site-generator-webpack-plugin, they say that you can use a combination of crawl: true
and providing multiple entry points for crawling in the paths:
plugins: [
new StaticSiteGeneratorPlugin({
crawl: true,
paths: [
'/',
'/uncrawlable-page/'
]
})
]
i didnt try that but maybe you tried and it doesnt work? Just curious
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.
@montogeek tbh I'm a little confused why the config changes were needed just to add the page titles. Did you try just import
ing the Content.json
file and looking for the corresponding page title from within there based on locals.path
? I thought the title
addition would be smaller than this (although I might be missing something).
This feedback is just from a glance though, I'll look through your changes a bit more to understand exactly what you did.
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.
Yes, that config change shouldn't be part of this PR.
I was a side change when navigating the site testing titles changed between pages.
webpack.prod.js
Outdated
@@ -7,6 +7,17 @@ const SSGPlugin = require('static-site-generator-webpack-plugin'); | |||
|
|||
// Load Common Configuration | |||
const common = require('./webpack.common.js'); | |||
const Content = require('./src/_content.json'); |
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'm starting to understand the approach now. You can't do it this way because _content.json
only exists after a build has occurred, meaning if you haven't run a build, the file won't exist and therefore this line will fail. You should take a similar approach, but do it all within the server.jsx
file.
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 way you won't have to change any configuration or touch any other parts of code. Then, if you remove the misc formatting things, this should be a pretty isolated, mergable PR (at least in my opinion).
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 think we could also .gitignore the _content.json? why is it in repo
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.
It is .gitignore
d. Everything starting with an underscore is.
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.
Just double-checked, yeah it doesn't exist in source control (at least not on the main rebuild
branch):
https://github.com/webpack/webpack.js.org/tree/rebuild/src
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.
true, my gitignore plugin was off, thank you for doublechecking
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.
Also, there may be a better approach for handling that content from DirectoryTreePlugin
point of view. If there's a more standard approach for this kind of thing I'm all ears. Feel free to create an issue over there if necessary.
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.
@skipjack I suspected as much, will move to server.jsx
file
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 think moving this part:
const paths = Content.children.reduce((paths, page) => {
if (page.type === 'directory') {
page.children.forEach(child => (paths[child.url] = child.title));
} else {
paths[page.url] = page.title;
}
return paths;
}, {});
...
let title = paths[locals.path];
To server JSX is actually a good idea, also i just tried
new SSGPlugin({
crawl: true,
paths: [
'/',
'/configuration/'
],
....
})
and it seems to work, but for some reason it also crawls outgoing urls from backers
@skipjack Addressed your comments |
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.
Aside from the minor comment I think this is good to go. I'll test to make sure as soon as I get a chance.
On a sidenote, I think the directory-tree-webpack-plugin
can provide some utilities for walking the tree (similar to how unified
provides tree walking utils). This would allow us to extract many of the utility methods (e.g. in Site.jsx
) outside of this repo to take the maintenance/testing burden off this site.
cc @jeremenichelli this type of abstraction is exactly what I think we've discussed to keep this repo as content focused as possible.
DISCUSSION.md
Outdated
@@ -14,7 +14,7 @@ this branch: | |||
- [ ] Finish re-incorporating mobile sidebar | |||
- [ ] Re-integrate google-analytics | |||
- [ ] Re-incorporate `redirects.json` | |||
- [ ] Populate page title in `server.jsx` (fernando) | |||
- [x] Populate page title in `server.jsx` (fernando) |
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.
Drop this to resolve the conflict (see comments on other other PRs for context).
src/server.jsx
Outdated
<meta name="theme-color" content="#2B3A42" /> | ||
<meta name="viewport" content="width=device-width, initial-scale=1" /> | ||
<title>{/* TODO */} | webpack</title> | ||
<title>{title} | webpack</title> |
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.
Shouldn't we add a check for index.md
? If I'm not wrong the result will be: webpack | webpack, maybe removing the title there and defaulting to webpack when it's not present.
src/server.jsx
Outdated
} | ||
|
||
return paths; | ||
}, {}); |
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.
Does it makes sense to generate a _paths.json
file after _content.json
is created? We could import it and avoid doing this every time the server file runs, it might improve performance on SSR considering we have lots of pages.
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.
If this is the case Fernando, we can leave it for further optimization and I can tackle that once this is merged :)
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 think better than another file would just be to have a walk
or find
utility to find the page node within the main tree (rather than creating a separate array and walking it).
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.
Good, to make it clear this is not a blocker for the PR to be merged.
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.
Yeah, I think once we've tackled everything I may try to spend a day or two just doing some cleanup and extraction of code to other packages so that it's fairly clean before going into master
.
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.
In #2108, I added a content-utils.js
file that should make things like this a breeze using the WalkContent
or FindInContent
method. I think we should get #2108 and #2074 merged into rebuild
and then really start a push to finish up the rest of these. From what I've seen, most of the rebuild
PRs are pretty close and may just need a little refactoring and abstracting to a separate package (e.g. remark
plugins). Skimming over them again now.
@jeremenichelli Addressed your comment, and also fixed weird characters issue: |
3298b94
to
f035ea1
Compare
@montogeek rebased and tweaked the logic to account for some This PR fixes the HTML layer titles but once the site is entered we need to dynamically change the title using something like |
It is better to do it here now, I will work on it later today |
@montogeek I'm gonna wrap this one up. With #2074 in and the content utilities some of the code here can be simplified and adding |
- Created a simple hash object to save paths and page titles - Use previous object for SSGPlugin since crawl wasn't working, it fails to collect all links ignoring 'configuration' section entirely.
…undefined` titles
0b1aac3
to
4ae8a04
Compare
Once the application is entered it acts as an SPA. This means we need to dynamically change the title here on top of the `server.jsx` static title population.
No description provided.