Skip to content
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

Merged
merged 7 commits into from
Jun 23, 2018
Merged

Add decss-style API #23

merged 7 commits into from
Jun 23, 2018

Conversation

taion
Copy link
Contributor

@taion taion commented Jun 7, 2018

@@ -20,13 +19,13 @@ const ButtonBase = styled('button')`
white-space: nowrap;
user-select: none;

${p => p.theme === 'primary' && css`
&.theme.primary {
Copy link
Contributor Author

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

Copy link
Contributor Author

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) {
Copy link
Contributor Author

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) {
Copy link
Contributor Author

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?

) {
if (propValue === true) {
modifierClassNames.push(styles[propName]);
} else if (propValue !== false && has.call(styles, propValue)) {
Copy link
Contributor Author

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)


export default styled;

export const css = () => {
Copy link
Contributor Author

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes please

Copy link
Contributor

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 {
Copy link
Contributor Author

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

Copy link
Contributor

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

Copy link
Collaborator

@ai ai Jun 7, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, &.color=green?

Copy link
Contributor Author

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

Copy link
Contributor

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

Copy link
Contributor Author

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"

Copy link
Contributor

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

@jquense
Copy link
Contributor

jquense commented Jun 7, 2018

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

@ai
Copy link
Collaborator

ai commented Jun 7, 2018

I like it 😍

It is more readable than styled-components

@jquense
Copy link
Contributor

jquense commented Jun 7, 2018

I don't see the win here, it's a lot more magic seeming...and less control

@ai
Copy link
Collaborator

ai commented Jun 7, 2018

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.

@ai
Copy link
Collaborator

ai commented Jun 7, 2018

@jquense what do you think of keeping both API? Simple &.prop for simple cases and template string ${ prop && … } for the complex with dynamic values

@taion
Copy link
Contributor Author

taion commented Jun 7, 2018

well, prettier doesn't mess this format up :p

in practice every case we have is either props.foo === 'bar' or props.foo, no?

we probably can't go much beyond this without something like a CSS parser, but the simplicity is worthwhile.

@@ -2,5 +2,8 @@
"extends": "4catalyzer-react",
"env": {
"browser": true
},
globals: {
"css": false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no globals!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fine :p

Copy link
Contributor Author

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? ;)

Copy link
Contributor

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

@taion
Copy link
Contributor Author

taion commented Jun 7, 2018

@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

@jquense
Copy link
Contributor

jquense commented Jun 7, 2018

We can remove it for now. Always easily add it back if needed

@taion
Copy link
Contributor Author

taion commented Jun 9, 2018

updated... this is the same API as decss now, minus the part where it breaks if you only emit camelcased class names

@taion
Copy link
Contributor Author

taion commented Jun 13, 2018

Thoughts?

@ai
Copy link
Collaborator

ai commented Jun 13, 2018

I like new prop-value syntax


&.primary {
Copy link
Contributor

@jquense jquense Jun 13, 2018

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..

@jquense
Copy link
Contributor

jquense commented Jun 13, 2018

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

Copy link
Contributor

@jquense jquense left a 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?

@jquense
Copy link
Contributor

jquense commented Jun 21, 2018

maybe we should support both tho?

@taion
Copy link
Contributor Author

taion commented Jun 21, 2018

make up your mind #23 (comment) 🤣

@jquense jquense merged commit 770ba48 into master Jun 23, 2018
@jquense
Copy link
Contributor

jquense commented Jun 23, 2018

lets give it a shot 👍

@jquense
Copy link
Contributor

jquense commented Jun 23, 2018

we can add back the old api as well if the double use-case arrises

@taion taion deleted the decss branch June 23, 2018 21:06
@kossnocorp
Copy link

Awesome! 👏

@taion taion mentioned this pull request Jul 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants