CSS objects as tw parameter and interpolations value

[tw-in-js]

CSS objects as tw parameter and interpolations value

[bebraw]

I wonder if there is really a use case for this kind of rule definitions?

tw({
  sm: 'w-1/2',
  md: 'w-1/3',
})

is handy when you are producing HTML from a JSON definition (my use case). I.e. consider the following:

{
  "component": "box",
  "tw": {
    "sm": "w-1/2",
    "md": "w-1/3"
  }
}

From my point of view, ideally both object notation and template literal syntax are supported. The former is useful for configuration based usage like mine while latter is likely for those that author JSX or some other format.

---

tw({
  '&::before': { content: '🙁' }
  '&::after': { content: '😊' }
})

That's a cool example and it would fit my component model as well.

[sastan]

is handy when you are producing HTML from a JSON definition (my use case). I.e. consider the following:

{
  "component": "box",
  "tw": {
    "sm": "w-1/2",
    "md": "w-1/3"
  }
}

Would this work for you?

{
  "component": "box",
  "tw": "sm:w-1/2 md:w-1/3"
}

or:

{
  "component": "box",
  "tw": "w(sm:1/2 md:1/3)"
}

or:

{
  "component": "box",
  "tw": ["sm:w-1/2", "md:w-1/3)"]
}

or:

{
  "component": "box",
  "tw": ["sm:(w-1/2 ...)", "md:(w-1/3 ...)"]
}

From my point of view, ideally both object notation and template literal syntax are supported.

If you mean with object notation is tw({ sm: '...', md: '...' }) then this would prevent the CSS object notation. Because we can not distinguish between rule objects and css objects.

---

tw({
  '&::before': { content: '🙁' }
  '&::after': { content: '😊' }
})

That's a cool example and it would fit my component model as well.

Cool!

Let's summarize the proposed APIs:

1. keep rule object notation and add css helper

tw({
  sm: 'w-1/2',
  md: 'w-1/3',
})

tw(css({
  '&::before': { content: '🙁' }
  '&::after': { content: '😊' }
}))

tw`sm:${css({
  '&::before': { content: '🙁' }
  '&::after': { content: '😊' }
})}`

const smiley = css({
  '&::before': { content: '🙁' }
  '&::after': { content: '😊' }
})

tw`sm:${smiley}`

2. drop rule object notation with (optional) css helper - to allow style re-use

tw("sm:w-1/2 md:w-1/3")

tw({
  '&::before': { content: '🙁' }
  '&::after': { content: '😊' }
})

tw`sm:${{
  '&::before': { content: '🙁' }
  '&::after': { content: '😊' }
}}`

const smiley = css({
  '&::before': { content: '🙁' }
  '&::after': { content: '😊' }
})

tw(smiley)
document.body.className = smiley

tw`sm:${smiley}`

Both APIs would still support template literals, strings, inline plugins, and arrays of those.

[bebraw]

Would this work for you?

{
  "component": "box",
  "tw": "sm:w-1/2 md:w-1/3"
}

The nice thing about this format is that I can easily produce "sm:w-1/2 md:w-1/3" from an object if I want to support the object notation I mentioned. Even the other one would be doable as a simple transformation on my side.

Maybe that's the point - if the string format is clear, then it's not a problem build object notation in user space on top of it.

[sastan]

This got me thinking...

In both cases we would add a css helper. If we do that and think of the css object as an escape hatch it would be not to bad to write:

tw`sm:${css({
  '&::before': { content: '🙁' }
  '&::after': { content: '😊' }
})}`

This additionally makes clear that the object is css and is a nicer to read than the current solution with a inline plugin:

tw`sm:${() => ({
  '&::before': { content: '🙁' }
  '&::after': { content: '😊' }
})}`

The rule object notation would stay. This would mean no API changes and we introduce a css helper.

Can we agree on that? @lukejacksonn

[lukejacksonn]

Seems pretty low overhead and like you say, it looks nicer and makes it clear that the contents is just CSS. Would be happy to export such a function!

[sastan]

fixed with in f4a0325