-
Notifications
You must be signed in to change notification settings - Fork 6
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
Multiple fonts support #58
Conversation
So 11ty can work with 'em!
TODO: - Apply proper class so the correct font is used - Loop over the other specimen components (grid and interactive controls)
const fontFiles = process.argv[2] || (await findFontFile(fontsDirectory)); | ||
|
||
// Initialise files | ||
writeFile( |
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 writeFile
calls are not await
ed now. I think the writes should be await
ed, to prevent race conditions with other writes.
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 call, will do.
|
||
const assert = (condition, message) => { | ||
if (!condition) { | ||
throw new Error(message); | ||
} | ||
}; | ||
|
||
const _appendFile = util.promisify(fs.appendFile); |
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 a fan of mutating things. I'd rather build up the whole result and write it at once, instead of appending things. Many things can go wrong with appending, you need to handle order etc. What do you think?
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.
Hmm. I'll see if I can refactor this.
@@ -14,7 +14,7 @@ <h2>Axes & Instances</h2> | |||
class="interactive-controls-slider" | |||
/> | |||
</li> | |||
{% for axis in axes %} | |||
{% for axis in font[1].axes %} |
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 this loop over all fonts? And why [1]
and not [0]
?
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's the way 11ty returns data in _data
: [0]
contains the directory name, and [1]
contains the actual data for each file. (In this case, axes.json
). The looping happens here (prettier smashes this into one line, not happy about that, but hopefully you can parse 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.
Ah clear!
The directory names for the generated data in ./_data is based on the classname. This in turn is based on a "slugified" name of the font. Maybe upon generating new _data, we should empty the dir? I got confused a couple of times by old font _data files lingering.
Grids are generated for all fonts, sliders only for variable fonts.
Decided to keep the refactoring for a later time, so we can move ahead now. Issue here: #59 |
@pascalw Thanks for the review & suggestions! |
Related: kabisa/specimen-skeleton-support#8