Feedback after migrating from classy-ui to stitches

[stitchesjs]

Feedback after migrating from classy-ui to stitches

[christianalfoni]

This is amazing feedback @CodingDive, thank you so much ❤️

1. Yes, I completely agree. That was a pretty amazing feature. I am running this issue and hoping it will result in allowing it: microsoft/TypeScript#38106. Like, there are ways to get around it by doing things like: css.marginTop(tokens => tokens.SPACE_70) , which would give you the type info.... we could also do css.marginTop.SPACE_70which would indeed also give you the type info I believe. The type info here would include typing for marginTop being a function as well... though it is certainly more straight forward. I would look into that 😄

2. Yeah, exactly, the experience of getting going and configuring is awesome :)

3. Yeah, lets see where we are at now with the latest update, where types has been improved 😄

4. Yes, indeed, we are not doing anything currently on the defaults. We could expose a set of tokens though that would give you a smoother experience out of the box. Also supporting more token categories is absolutely possible. If you want to create a tokens configuration without thinking about current constraints that would be awesome... just create a GIST or something. Then that might end up as a default set of tokens in the library 😄

5. Ah, yes, I believe uppercasing it all is the best, though I think that tokens should probably be exposed as a property instead of a value to the function as explained above. Let me try this first and then you will get a very nice separation there. Just have to check out if we can bring in the typing :)

6. Yes! This surprised us as well! The reason it works like this is so that we inject the styling needed at the point of consumption... though this in theory seems smart, it might not necessarily be more performant. But yeah, in discussion, and will document this yes

Thanks so much again for the encouragement and feedback! 😃

[CodingDive]

Thank you so much for the detailed response.

having duplicate APIs has a high cost in maintenance, documentation and understanding the library.

I believe so too.

css.color.RED_500 
css.color('RED_500', ':hover') 

The only reasonable alternative I see is to go full token-based for props/values but not repeat the mistake of classsy-ui and pass the pseudo-selectors into a function.

css.color.RED_500,
css.on(':hover').color.RED_500,

When used with data-attributes and selectors see #7, we could optionally get some nice type support when passing in an enum of data-attributes.

enum LISTBOX_DATA {
 DISABLED_OPTION: '[data-reach-listbox-option][aria-disabled="true"]',
}

// assuming we keep the 'on' function for solely pseudo-selectors and 'when' for data-attributes. Those two could also be merged as a single function whose value gets prepended before the property & token as is currently the case for the second argument.
 
css.when<LISTBOX_DATA>('DISABLED_OPTION').cursor('not-allowed')

This would just make it a bit nicer to work with data attributes as the atomic approach of stitches would make me put most static data attributes into an enum anyhow. The point here is not necessarily the example and the generic enum argument gimmick, but show the potential possibilities of having an extra function for pseudo selectors. It would also certainly be more readable than the current argument order as addressed below.

---

css.color('RED_500', ':hover') 

Another thing on my stitches API wishlist would be to make the ordering of the arguments agnostic since we are used to writing selectors => property & value from left to right.

css.color(':hover', 'RED_500') 

Is definitely easier to read for me but it's not a big deal either way. I just wanted to add it here since it would've been very difficult to fix this in classy-ui, while I believe the function-based approach of stitches to be flexible enough to swap them around easily.

[christianalfoni]

Okay, so I played around with the typing and we can indeed fix this. If we have added tokens you can write it as:

css.color.RED_500 // With all the type documentation
css.color('red') // Is still possible when you need to override

The problem is pseudo selectors, as you can not express those without a function:

css.color.RED_500 
css.color('RED_500', ':hover') 

Would have to be like this... hm... have to think on that 😄

[christianalfoni]

Okay, discussed a bit and we need to wait with this. The reason is that having duplicate APIs has a high cost in maintenance, documentation and understanding the library. I certainly see the benefit of having a token documented to what CSS it produces, but at the same time... tokens are really there for you to NOT think about the underlying value. The underlying values should freely be able to change without you worrying about it.

So yeah, I still agree with you, it was amazing to have that information there... but yeah, here you have a current state of things at least 😄

Please discuss more if you want to!