-
-
Notifications
You must be signed in to change notification settings - Fork 181
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
Move featured chapter quotes from Jinja2 template to JSON file #1103
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.
I notice that the .json
files don't have a EOF line
Fixed! |
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 good to me code wise and functionality wise. Not fully sure if I am missing something in regression terms.
Thanks for the review @SaptakS ! I’m pretty confident in regression issues. @rviscomi wouldn’t mind you casting your eye over this if you have the time as a bit of a change in direction. And I feel the JavaScript is a bit verbose and you always have better ways to write this to look neater! For context this is setup for #1104 |
Will do. I plan to get to this in a few days if there's no hurry. |
"stat_1": "89%", | ||
"stat_label_1": "Sites with more third-party code than first-party", | ||
"stat_2": "83%", | ||
"stat_label_2": "Sites that use jQuery", | ||
"stat_3": "4.6%", | ||
"stat_label_3": "Home pages using React" |
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'd like to see these formatted differently so that the stat and the label are more intrinsically linked together besides the _1, _2, _3 suffix. How about as an array of objects/arrays?
"stat_1": "89%", | |
"stat_label_1": "Sites with more third-party code than first-party", | |
"stat_2": "83%", | |
"stat_label_2": "Sites that use jQuery", | |
"stat_3": "4.6%", | |
"stat_label_3": "Home pages using React" | |
"stats": [ | |
{"89%": "Sites with more third-party code than first-party"}, | |
{"83%": "Sites that use jQuery"}, | |
{"4.6%": "Home pages using React"} | |
] |
Alternatively:
"stat_1": "89%", | |
"stat_label_1": "Sites with more third-party code than first-party", | |
"stat_2": "83%", | |
"stat_label_2": "Sites that use jQuery", | |
"stat_3": "4.6%", | |
"stat_label_3": "Home pages using React" | |
"stats": [ | |
["89%", "Sites with more third-party code than first-party"], | |
["83%", "Sites that use jQuery"], | |
["4.6%", "Home pages using React"] | |
] |
featured_quote_filename = 'templates/%s/%s/featured_chapters.json' % (lang, year) | ||
if os.path.isfile(featured_quote_filename): | ||
with open(featured_quote_filename, 'r') as featured_quotes_file: | ||
featured_quotes = json.load(featured_quotes_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.
Should we cache this in memory?
// Get a random quote using JS for those reloading cached CDN page. | ||
// We do as much as possible before HTML so we can replace the server | ||
// generated quote quickly without a flash of the server side quote |
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 not sold on this. The contributors page was one thing because I can see the value of giving each contributor equal prominence. But a chapter can be featured for a few hours at a time and I don't think there's any expectation from readers or authors that this should randomly update on refresh.
The overhead in both the HTML payload and the JS code just don't seem worth it for a feature that would be used infrequently and adds little to the UX.
If you're still convinced that this is the right change, could we continue this discussion in another issue and decouple it from the JSON change in this PR?
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 you’re probably right. Having a chapter “featured” for a few hours is more expected. Was so preoccupied with whether or not I could that they didn't stop to think if I should 😁
Given that, should we even move to JSON or just stick with the Jinja2 template instead? We could still dynamically generate that with an EJS template like we do for the ebook. It would be an extra EJS template but as long as we use the .ejs.html naming convention we use for ebook that should be fine. Or do you think we will ever use these quotes elsewhere where having them in JSON format would be helpful?
@@ -22,3 +22,6 @@ | |||
|
|||
<a href="https://github.com/HTTPArchive/almanac.httparchive.org#contributing" class="btn">Join the team</a> | |||
{% endblock %} | |||
|
|||
{% block featured_chapter%}Featured Chapter{% endblock %} |
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.
The 2020 home page doesn't include a featured chapter section yet. Is this needed?
In a separate issue, could we also explore DRY solutions to reduce the duplication of language-specific text blocks across year templates?
I'm going to close as decided to stick with templates. |
This PR moves the featured chapter quotes to JSON which has several advantages:
base/2019/index.html
template