-
Notifications
You must be signed in to change notification settings - Fork 59
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
Add decss-style API #23
Conversation
example/src/Button.js
Outdated
@@ -20,13 +19,13 @@ const ButtonBase = styled('button')` | |||
white-space: nowrap; | |||
user-select: none; | |||
|
|||
${p => p.theme === 'primary' && css` | |||
&.theme.primary { |
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.
so, as long as you have nesting enabled, this decss-like API works
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.
ok, so this also would let you do primary="theme"
, but... come on
@@ -99,37 +81,6 @@ export default function plugin() { | |||
return style; | |||
} | |||
|
|||
function extractNestedClasses(path, className, cssState, hoistImport) { |
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 figure this isn't super necessary if we have the nesting-based API?
delete childProps.innerRef; | ||
childProps.ref = props.innerRef; | ||
|
||
if (hasModifiers) { |
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.
probably better to iterate through props rather than iterating through defined styles?
src/runtime/styled.js
Outdated
) { | ||
if (propValue === true) { | ||
modifierClassNames.push(styles[propName]); | ||
} else if (propValue !== false && has.call(styles, propValue)) { |
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.
maybe we should camel-case propValue
strings (and perhaps propName
... though anybody using non-camel-case prop names but enabling camel-casing in the css modules transform deserves what they get)
src/runtime/styled.js
Outdated
|
||
export default styled; | ||
|
||
export const css = () => { |
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.
bleh i didn't realize the docs suggested using this in all cases. should i add it back?
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 please
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.
ping
README.md
Outdated
border: 1px solid blue; | ||
} | ||
|
||
&.color.green { |
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.
we could do the decss thing of .color-green
as well... that would definitely require pulling in lodash/camelCase
, though. also it wouldn't let us delete the prop if the value doesn't match. it would avoid the weird precedence things here, though, and it'd prevent green="color"
from working
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 am not sure i understand the extent to which this all works...what is cruz of the logic, you check all classes and see if they map to a name or a bool prop?
It's not super obvious to me that .color
here is functioning as a prop name, while green is the value, even tho both and the inverse work as well
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.
+1, &.color=green
?
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'd have to be .color-green
, and because of camelcasing things it'd get munged into .colorGreen
, and we'd support both color="green"
and colorGreen={true}
as props, but that's not too important
right now the logic is going through all the props and seeing which ones match classes
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 like that better, but it's probably not possible without adding a css parser. My only concern there is we have no idea waht flavor of css the user is writing so it's tough to try and parse it (e.g. LESS, SCSS, custom postcss) I don't know that we'd get a reliable AST without user imput, but you'd be the expert there :P
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 so i think i'll just do the dashed class names and pull in lodash/camelCase
? so you'll do .theme-green
, but we'll look for .themeGreen
and .theme-green
when you do theme="green"
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 like that better, the cost of the lodash function will be small enough
Idk this API seems strictly worse no? It's the same for the simple case but doesn't allow any complex prop to class mappings or dynamic ones |
I like it 😍 It is more readable than styled-components |
I don't see the win here, it's a lot more magic seeming...and less control |
I like this API even if it is limited because you don’t need dynamic properties in most of the cases. Most cases are simple. So we should have the simple solution for them. |
@jquense what do you think of keeping both API? Simple |
well, prettier doesn't mess this format up :p in practice every case we have is either we probably can't go much beyond this without something like a CSS parser, but the simplicity is worthwhile. |
example/.eslintrc
Outdated
@@ -2,5 +2,8 @@ | |||
"extends": "4catalyzer-react", | |||
"env": { | |||
"browser": true | |||
}, | |||
globals: { | |||
"css": false |
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.
no globals!
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.
fine :p
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.
so does that mean all of our code is using this the wrong way by using this as a global? ;)
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.
its using it in a "deprecated" way, I left the auto-assume global for the bare css
to not break our code, but most every other lib requires an import, which i think makes sense
@jquense should we keep the old API or not? it makes it easier to tell whether there are modifiers if we only have the "normal" class name, but i guess we could look for the class names that start with "variant" or whatever |
We can remove it for now. Always easily add it back if needed |
updated... this is the same API as decss now, minus the part where it breaks if you only emit camelcased class names |
Thoughts? |
I like new |
|
||
&.primary { |
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 essentially requires that you have a nesting feature compile set up, which means no usage with plain css..
this api is nice, but it does require the user now have some specific preprocessor set up in addition to css-modules, at the very least it requires postcss-loader |
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 ok with giving this a shot, we should update the docs to say that nesting is required no?
maybe we should support both tho? |
make up your mind #23 (comment) 🤣 |
lets give it a shot 👍 |
we can add back the old api as well if the double use-case arrises |
Awesome! 👏 |
cc @jquense @ai