You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a consumer, having too many ways of doing things can lead to having some messy code base.
While Flame has some neat features, it still feels kinda awkward to use when it comes to deviating from whatever has been pre-established. Even with the inclusion of style-props, we still can't hit the "100%" fits all solution. That's just a limitation of the style-prop itself, you can only modify 1 css style per prop. Currently, should we want to handle advanced use cases that are not planned, we would need to:
Add more props
Extend using either styled or the css prop jsx pragma
Both solutions kinda suck, as we're:
Further increasing prop api complexity
Diverting some core functionalities that the library should handle to the underlying implementation (aka, we let emotion do it's thang)
Requirements
In order to have a better API and a just more fun to use component system we need to limit the amount of "back and forth" between various ways to extend and have the component system handle pretty much all the base styling needs.
A user should not have to extend a component via styled to get overrides.
A component API should not explode when trying to do overrides.
A user should not have to install yet another babel plugin.
A user can easily do responsive css
Proposal
There's a few things we can do. Some changes can be had immediately, while others might take some time.
The first thing we can do is create our own home grown css prop that is baked into our components.
see https://github.com/rebassjs/rebass/blob/master/packages/reflexbox/src/index.js#L37 for implementation details. Essentially, rebass has 2 props, css and sx, that are baked directly into rebass components. We can do something similar, except we will not have a sx prop and instead just use css that is automatically hooked into the theme values. Only having css prop can cause conflicts with the jsx pragma of props. Easiest solution: Use rebass and re-export only the components we want.
By doing this we avoid adding yet more styled-system props and grant you full access to ALL theme values as well as just regular old css in a single prop.
The second thing is we're adding back classnames on some components (tbd). This might seem like the funkiest thing ever, but this will enable us to target specific portions of a component easily via a top level css prop. Basically, the classnames are only there to serve as markers so we can quickly do edits without having to go through the whole render slot approach of jamming a component inside a prop.
Last but not least, we're gonna cleanup the theme file just a bit. Namely collapsing some properties together (like shadows) and renaming some values, as they are kinda long winded to write down
Out of Scope
Fixes relating to CSS specificity or stuff like that. That's for another time.
Risks
There may be a collision between our css prop and the jsx css pragma prop. If that happens, we'll need to do like rebass and split our styling into two props css for regular non themed css and sx for the magical augmented css
Alternatives
¯\_(ツ)_/¯
Resolution
Expect a PR in a couple of phases.
We'll start by adding this functionality to Box, Flex and Text as those are our fundamental components. From there, we're gonna modify existing components to use the new fundamental components and have a way to easily override sub-components.
The text was updated successfully, but these errors were encountered:
glambert
changed the title
Styling API consolidation and a just more fun to use component API system
RFC: Styling API consolidation and a just more fun to use component API system
Feb 3, 2020
Background
As a consumer, having too many ways of doing things can lead to having some messy code base.
While Flame has some neat features, it still feels kinda awkward to use when it comes to deviating from whatever has been pre-established. Even with the inclusion of style-props, we still can't hit the "100%" fits all solution. That's just a limitation of the style-prop itself, you can only modify 1 css style per prop. Currently, should we want to handle advanced use cases that are not planned, we would need to:
styled
or the css prop jsx pragmaBoth solutions kinda suck, as we're:
Requirements
In order to have a better API and a just more fun to use component system we need to limit the amount of "back and forth" between various ways to extend and have the component system handle pretty much all the base styling needs.
styled
to get overrides.Proposal
There's a few things we can do. Some changes can be had immediately, while others might take some time.
The first thing we can do is create our own home grown
css
prop that is baked into our components.see https://github.com/rebassjs/rebass/blob/master/packages/reflexbox/src/index.js#L37 for implementation details. Essentially, rebass has 2 props,
css
andsx
, that are baked directly into rebass components.We can do something similar, except we will not have aOnly having css prop can cause conflicts with the jsx pragma of props. Easiest solution: Use rebass and re-export only the components we want.sx
prop and instead just usecss
that is automatically hooked into the theme values.By doing this we avoid adding yet more styled-system props and grant you full access to ALL theme values as well as just regular old css in a single prop.
The second thing is we're adding back classnames on some components (tbd). This might seem like the funkiest thing ever, but this will enable us to target specific portions of a component easily via a top level
css
prop. Basically, the classnames are only there to serve as markers so we can quickly do edits without having to go through the whole render slot approach of jamming a component inside a prop.Last but not least, we're gonna cleanup the theme file just a bit. Namely collapsing some properties together (like shadows) and renaming some values, as they are kinda long winded to write down
Out of Scope
Fixes relating to CSS specificity or stuff like that. That's for another time.
Risks
There may be a collision between our
css
prop and thejsx css
pragma prop. If that happens, we'll need to do like rebass and split our styling into two propscss
for regular non themed css andsx
for the magical augmented cssAlternatives
¯\_(ツ)_/¯
Resolution
Expect a PR in a couple of phases.
We'll start by adding this functionality to
Box
,Flex
andText
as those are our fundamental components. From there, we're gonna modify existing components to use the new fundamental components and have a way to easily override sub-components.The text was updated successfully, but these errors were encountered: