[roadmap] sheetify v6

Been using sheetify for a while now, and feel there's some rough edges still. In this issue I try and outline which problems I've been experiencing, and suggest solutions on how to fix 'em. Comments and suggestions super welcome; if we need to break stuff this is the place to mention it

problems

insert-css as a peer dep is hella annoying and probably makes for a not-so-great user experience - using sheetify right now doesn't "just work" and yeah it would be cool if it did
we don't support inline globals, which would be like a cool thing to support as it allows for inline var declaration, overrides and other stuff - people I'm working with right now have requested this already and kinda confirmed my idea this would be neat - Don't differentiate between host and non-host #98 | Support for @apply Rule #91 | Variables don't work in template strings #97 (ish)

todos

make insert-css a file in sheetify that can be required in, removing the peer dep (pr
patch css-extract to also detect the sheetify/insert (minor patch; just pick up more files)
merge feat(prefix): drop support for non :host prefix postcss-prefix#9 so only :host properties are prefixed

And that's it. Suggestions and thoughts super welcome!

@yoshuawuyts

hey @yoshuawuyts, sounds good to me. 👍

from my usage of sheetify, i really want to pass in style variables (as in say from require('./styles')) to each style declaration (#54, #97). unfortunately it's not easy unless we move to doing runtime inline styles instead of compiled string compilation, sooo yeah. 😄

@ahdinosaur

@ahdinosaur yeah a simpler way would be to declare css variables in a :root element in some index file, and then import all other files. Order in sheetify is guaranteed so you could run a transform over the whole bundle which would then resolve the vars. Gets you vars across the board - not convinced we should do fancy interpolation stuffs / runtime parsing as that complicates stuff a bunch

e.g.

const css = require('sheetify')

css`
  :root {
    --main-bg-color: brown;
  }
`

/* can be in another file */
css`
  .foo {
    background-color: var(--main-bg-color);
  }
`

@yoshuawuyts

@yoshuawuyts The above example looks good to me 👍

@yoshuawuyts

@yoshuawuyts you're right that's way simpler, thanks for the suggestion. ✨

Patches are done; can release sheetify@6 when these are merged:

yay!

when using it like you suggest above, doesn't that encourage the use of a lot of global variables?

What if i have many components that were authored by different people, which used the same name for their variables, maybe even set those variables... how can i make sure my global css variable won't override or be overridden by a component that uses and sets it too?

what about

const css = require('sheetify')

var x = css`
  :root {
    --main-bg-color: brown; /* will be auto-suffixed */
  }
`

/* can be in another file */
css`
  .foo {
    background-color: var(${x[':root/--main-bg-color']});
  }
`

then maybe somewhere in a root component that uses a lot of other components, maybe sheetify can offer the sum of all variables that have been defined in all the levels of nested components, so i can generate a style tag that sets all the values for all the variables... like maybe

var css = require('sheetify')
var yo = require('yo-yo')

Object.keys(css.vars()).forEach(x=>console.log(x)) // to see what is available for theming
// then later - remove the line above and replace it with something like:
css.vars()[':root/--main-bg-color'] = 'pink'

That wouldn't work as sheetify always returns a prefix. Having multiple
return types based on content feels off - besides Im not really seeing the
added value in the example. I understand globals are not ideal but then
again if variable name conflicts start to become an issue it might be time
to rethink what you're trying to do with CSS anyway haha.

On Wed, Nov 16, 2016, 17:35 Alexander Praetorius notifications@github.com
wrote:

what about

const css = require('sheetify')

var vars = css`

:root { --main-bg-color: brown; } /* can be in another file */ css .foo {
background-color: var(${vars[':root']});  }`
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#105 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACWlenYQgq2d-RMpHw3Yav5BKeSSRutgks5q-zDTgaJpZM4KsOHD
.

Released as v6.0.0 🎉

oh, didnt know sheetify is prefixing - guess that's fine too.

I try to build components which are white labeled pages made up of footer components and header components, made up of smaller components. If those components are written by different people or maybe by different me over time... i might not always remember what kind of css variables or names i used in all those different components, like: button, searchbar, signup form, image slider, menubar, and so on...

But once i pull all of them in to build a landing page component, how do i theme it?

I think that's were the basic idea from above comes from. Of course, how to express that in syntax is secondary to me.

I would appreciate some thoughts on how to deal with "complex" components made up of many sub components that i would like to theme and customize. I think i might not remember all the details, but something like css.vars() is a question from me to the component, so that it basically tells me all the stuff i can customize... ...maybe

yeah so you might be looking for something closer to styled-elements which
does all this during runtime - personally I don't think having theming
convenience is beneficial for components; being able to append classes and
later prune them is much more flexible I've found (e.g. the approach we're
taking with base-elements https://github.com/yoshuawuyts/base-elements) -
hope this somewhat answers your question!

On Sat, Nov 19, 2016 at 5:11 AM Alexander Praetorius <
notifications@github.com> wrote:

oh, didnt know sheetify is prefixing - guess that's fine too.

I try to build components which are white labeled pages made up of footer
components and header components, made up of smaller components. If those
components are written by different people or maybe by different me over
time... i might not always remember what kind of css variables or names i
used in all those different components, like: button, searchbar, signup
form, image slider, menubar, and so on...

But once i pull all of them in to build a landing page component, how do i
theme it?

I think that's were the basic idea from above comes from. Of course, how
to express that in syntax is secondary to me.

I would appreciate some thoughts on how to deal with "complex" components
made up of many sub components that i would like to theme and customize. I
think i might not remember all the details, but something like css.vars()
is a question from me to the component, so that it basically tells me all
the stuff i can customize... ...maybe

—
You are receiving this because you modified the open/close state.

Reply to this email directly, view it on GitHub
#105 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACWlesdzvEiEn1odzPFBYhHVDZI9hr6cks5q_nbegaJpZM4KsOHD
.

Navigation Menu

Repository navigation

[roadmap] sheetify v6 #105

problems

todos

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[roadmap] sheetify v6 #105

Description

problems

todos

Activity

ahdinosaur commented on Nov 9, 2016

yoshuawuyts commented on Nov 9, 2016

yoshuawuyts commented on Nov 9, 2016

Kriesse commented on Nov 11, 2016

ahdinosaur commented on Nov 13, 2016

yoshuawuyts commented on Nov 16, 2016

serapath commented on Nov 16, 2016

serapath commented on Nov 16, 2016

yoshuawuyts commented on Nov 16, 2016

yoshuawuyts commented on Nov 16, 2016

serapath commented on Nov 19, 2016

yoshuawuyts commented on Nov 19, 2016

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions