-
Notifications
You must be signed in to change notification settings - Fork 16
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
Nuclear refactor #74
base: development
Are you sure you want to change the base?
Nuclear refactor #74
Conversation
|
@theorosendorf Before this gets merged (assuming it will), if you want to push an RC package to NPM, I'll test it out in production on GRF. |
…o k/core-refactor
If anyone wants to try out the RC package, it's here: https://www.npmjs.com/package/textblock/v/1.0.2 or
|
Hey @kcargile — Just to confirm, is the file being called in the demo via unpkg, the minified version of this refactor? |
@kcargile — I'd like to change "Variable Grade" to "Variable Weight" because when we made this, variable fonts were new and no one was actually doing graded weights. The script actually adjusts weight so we should call it what it is. Then later, we can add additional variable font features. Also, for the sake of readability and usability, I think it would be best if we semi_SnakeCase the parameter names. Perhaps like All of this is just find and replace, right? |
It points to the minified version of the most recent stable version. In other words, it won't point to the refactored version until the PR is merged and a new major stable version is published on NPM. That is, demo is pointing to the older stable version. Not ideal since there's technically drift there, but I thought it didn't make sense to pin a version on the demo, since this would mean having to update the unpkg import every time any type of change (patch, minor, major) was merged into the mainline... There's probably a way to automate this (pinning the unpkg version) via CI/CD so that it's always consistent. If you want to open an issue, I'll explore some options. |
Ya. Find and replace in the code, docs, demo site, and so on. |
Hey @kcargile – I included this on a local version of the textblock.io site and it doesn't seem to be scaling the font sizes, only line heights. I switched to the syntax that the RC1.0.1 version is using. Any thoughts? Would it be helpful for you to see that branch of textblock.io I'm working in? |
Rut roh. Let me take a look and see if I can figure out what's broken. |
Here's the branch I'm testing in if you need to look there: https://github.com/theorosendorf/textblock.io/tree/textblock-refactor-test |
@theorosendorf Did changing the variable names fix this? I'm using the RC version on GRF and it seems to be working there 🤔 |
This one is pretty big and will need a good bit of testing before it goes to NPM, but incorporates most of the changes I've been using on some of my own websites.
This is a major version bump and contains breaking changes.
Here's what changed:
./dist
(npm run build
)@latest
on unpkgA few important notes:
I added filtering to remove non-HTML (HTMLElement) DOM nodes. This will prevent resizing other element types, e.g. SVGs, that don't share a common (styling) API. Not sure if this is desirable.
I added the following guard:
This seems like an edge case, but not sure if returning 0 is desirable.
The configuration and instrumentation options are pretty basic. There may be more debugging output that's relevant. It might also be desirable to add an optional config file (e.g.
textblock.config.js
) to set these and provide the ability to override defaults in a later version.Updates to the README are coming in a subsequent commit.Finally, I wasn't able to test publishing to NPM using the new build configuration. I propose that we automate this process via GHA on merge to the mainline. Happy to submit a PR for this later if it's useful.