-
-
Notifications
You must be signed in to change notification settings - Fork 98
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
Allow style component to be used as plugin #159
Conversation
Pull Request Test Coverage Report for Build 687852949
💛 - Coveralls |
size-limit report 📦
|
Try the Preview Package
This PR has been published to npm.pkg.github.com as Install/Update Configure your NPM client (click to expand)
Using the command line: npm config set //npm.pkg.github.com/:_authToken <READ_PACKAGES_TOKEN> --global
npm config set @tw-in-js:registry https://npm.pkg.github.com --global # For npm
npm install --force twind@npm:@tw-in-js/twind@pr159
# For yarn - upgrade implies install
yarn upgrade twind@npm:@tw-in-js/twind@pr159 |
Cool :D thanks for working on this. Regarding the serialization issue, I find the current and alternative approaches a bit difficult to read and grasp the structure. I can't immediately tell whether E.g. after experimenting with the plugins API further, I noticed a syntax like |
Small correction (nit picking): the |
I like this proposal :) The proposed classname syntaxes are not without their pitfalls. I imagine that there may be edge-cases such as variant names/values containing Lines 79 to 89 in 7d9cc19
= key/value pairs hard to read, but I know from experience / experimentation that the current implementation of the plugin "parts" tokenizer (i.e. - -separated segments) is a bit "picky" (e.g. discards ( and ) characters, and I think curly braces too).
As some of you may know ( #147 ), my Preact WMR -based build system removes the Twind runtime in production builds (static SSR), which means that the Twind runtime exists in-browser only at development time, and otherwise in NodeJS during the prerender pass. In my current implementation I handle So, with this plugin-based |
About the syntax We should keep in mind that people will demand autocompletion for that. So it should be "autocompletable". Maybe I just need to extend the typescript plugin to have special handling. In that case, it should be distinguishable from other values.
Between Edit: The parser would do the same as it does for arbitrary values (skip until closing bracket). |
26239da
to
137af16
Compare
This PR allows a style component to be used as a plugin based on an idea by @mattrossman
Here are some example of possible class names (see open issues below for alternatives:
Open Issues
btn-{size:md,outline}
btn-{size=md,outline}
x-size=md-camelCase
(implemented in this PR)x-size=md_camelCase
&x-size=md_camel-case
x-size=md--camelCase
&x-size=md--camel-case
x-size=md&camelCase
&x-size=bar&camel-case
Usage