blog: designing for composition #716
Conversation
facebook-github-bot
added
the
CLA Signed
workflow: benchmarks/sizeComparison of minified (terser) and compressed (brotli) size results, measured in bytes. Smaller is better.
|
| now offer a way to merge styles. | ||
|
|
||
| Despite all the tools, style composition remains a challenge. From headless | ||
| UI libraries to design system components that are copied to your own codebase, |
There was a problem hiding this comment.
nit: double space
| UI libraries to design system components that are copied to your own codebase, | |
| UI libraries to design system components that are copied to your own codebase, |
| inline styles. To form a mental model, it can be helpful to think of StyleX | ||
| as "inline styles without the limitations". | ||
|
|
||
| StyleX gives you the ability to use capabilities such as pseudo classes and |
There was a problem hiding this comment.
| StyleX gives you the ability to use capabilities such as pseudo classes and | |
| StyleX allows you to use capabilities such as pseudo classes and |
| By the time we made the conscious decision to model StyleX after inline styles, | ||
| StyleX had already been in development for a while and had evolved organically | ||
| inspired by React Native's `StyleSheet` API, which was itself inspired by inline |
There was a problem hiding this comment.
| By the time we made the conscious decision to model StyleX after inline styles, | |
| StyleX had already been in development for a while and had evolved organically | |
| inspired by React Native's `StyleSheet` API, which was itself inspired by inline | |
| By the time we made the conscious decision to model StyleX after inline styles, | |
| StyleX had already been in development for a while, organically inspired by React Native's StyleSheet API—which itself was influenced by inline styles. |
| React Native pioneered the approach of merging purely by key, and assigning | ||
| different priorities to different properties. Longhand properties have a higher | ||
| priority than shorthand properties. So, while you *can* end up | ||
| with a style object that has both `padding` and `paddingTop`, `paddingTop` will | ||
| take precedence regardless of the order in which they are applied. |
There was a problem hiding this comment.
should we define and use property specificity and application order here
| we believe many of these tools need to exist entirely because of the inconsistencies | ||
| of merging styles. | ||
|
|
||
| We believe that we've built the first solution with style composition at its very core. |
There was a problem hiding this comment.
Meta engineering write ups typically focus on describing specific problems/opportunities we encounter, the root cause, how it was resolved, and the results seen. In that context, I think the voice and framing used throughout this draft could be revisited.
Another concern I have with this post is that one of the primary goals of StyleX was to optimize the output. One of the defaults doesn't do that, but discussing it in the post isn't particularly relevant to the main topic of the post.
There was a problem hiding this comment.
This is very useful feedback! It helps me use a particular framing to do a second draft.
|
|
||
| So, when it came to designing StyleX, we decided to model our styles after | ||
| inline styles. To form a mental model, it can be helpful to think of StyleX | ||
| as "inline styles without the limitations". |
There was a problem hiding this comment.
It does have limitations so this may be misleading
Blog Post
A blog post that describes how we arrived at certain API design decisions and how we
prioritise predictable style composition.