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

RFC: Styling API consolidation and a just more fun to use component API system #74

Open
xdrdak opened this issue Jan 31, 2020 · 0 comments
Labels
rfc Request for comments

Comments

@xdrdak
Copy link
Contributor

xdrdak commented Jan 31, 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:

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

@glambert 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
@glambert glambert added the rfc Request for comments label Feb 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rfc Request for comments
Projects
None yet
Development

No branches or pull requests

2 participants