Replies: 3 comments 1 reply
-
Thanks for the edit @nmn I've also tried cleaning up the post a bit to make it easier to follow. |
Beta Was this translation helpful? Give feedback.
-
I just put an RFC #534 to describe an API that would likely be the solution to the concerns you expressed here. I've described the proposed API and the constraints and reservations for why it hasn't been done so far. But to answer your specific proposal: <StyleTester
consumerStyles={{
backgroundColor: {
default: 'green',
[DARK]: {
default: 'yellow',
},
},
}}
/>; This is not a valid API as any styles need to be wrapped in a function call for the compiler to detect and transform. The RFC proposes this instead: <StyleTester
consumerStyles={stylex.inline({
backgroundColor: {
default: 'green',
[DARK]: {
default: 'yellow',
},
},
})}
/>; |
Beta Was this translation helpful? Give feedback.
-
Closing discussion, as it be continued on the RFC. |
Beta Was this translation helpful? Give feedback.
-
I started testing out the use of
StyleXStyles
today, and it has me thinking about Developer Experience, auto complete with TS, and documentation.So far I have used
stylex.create
and used it to set up variants. And that method works well for giving the consumer of my component library a bit of a developer experience with prompts and autocomplete. The variant is just a prop with constrained string optionsvariant?: 'primary' | 'secondary' | 'destructive' | 'icon';
When the developer goes to use my component, it will prompt them with the prop options,
variant
being one of them, as well as the constrained value options (primary, secondary, etc). Additionally it will get picked up by Storybook which makes documentation and demos easier. So far so good!Let’s look at the
StyleXStyles
DX. Here is how I set it up.Component Library
And then the consumer of the component library, in their app they would do something like this
While hovering on
consumerStyles
in my IDE, I got this feedback.And I was thinking to myself, wouldn’t it be nice if I could kinda shortcut some of this code. If, at this point, we know we are expecting an object with a key of
backgroundColor
and a value of one of the options, could this be a way to get it done?By the way, I know there is a ton happening here and I have no idea what is going on behind the scenes, hope you don't mind my hypothetical pondering.
If it could be written that way by the consumer of my component, then perhaps they could be presented with some DX and IDE feedback/prompts/autocomplete
However when using
StyleXStyles
, the consumer of my component won't get any feedback or prompts when they go to usestylex.create
to create a style object to pass in via a prop. Rather they would need to know everything about it before they go to write it. What CSS properties will it accept? What values will it accept for each of those properties?If it comes down to documentation, I'll have to work on that some more. In older libraries I built (Emotion for example), most style choices like this were fed in as props, and so they integrated very easily with Storybook args and made documentation a bit easier. Much like the style variants as documented
Perhaps the recommendation is to use
StyleXStyles
sparingly? Though it does seem like a key part of the library.I would love to know more about the workflow you all have been using with Stylex.
Thanks for all the feedback, and thanks for listening!
Beta Was this translation helpful? Give feedback.
All reactions