Simple component library

[LexSwed]

Hello!

Just wanted to share my experience with stitches. Here's a simple component library I built with stitches: https://fxtrot-ui.vercel.app/. Here's a GitHub Link (not production ready, it's just me trying tools)

The initial idea was to take some existing design system, but take colors and units from TailwindCSS and use React Aria to ease accessibility development and avoid thinking to much about components API. Learn new tooling in the meanwhile.

Experience

The main experience with stitches is awesome:

• easy to use and setup - no build setup required (like in treat that makes you have bundler setup issues)
• superb TypeScript support (almost, see below)
• feels like you're developing something very fast, especially thanks to atomic CSS. I didn't have this feeling with emotion or styled-components.

(possible) Issues

• <Box css={{ display: 'inline-block', width: '100px', }} /> is not a solution as it creates a new object on every render. Sometimes I feel that exposing css prop is useless, people can just create own components using styled, but then sometimes all you want is a simple style={{ width: '100%' }} and it's a nice feeling when you avoid creating a new component just for that. So I exposed StylesRecord type to ease the writing of custom css objects outside React render cycle, example usage so you get nice autocomplete for style objects. But I don't like it since this way developer creates disconnection between code and styles, as styles exist outside component logic. So, I had to make some code poop I'm not proud of to make the API more "automatic to memoize" (can I say it this way?) needed styles, so the API becomes similar to styled-system: <Box width="100%". It's quite restrictive, but sometimes it's good (Design Systems is a separate topic). A solution to this could be a babel plugin similar emotion one to extract inline css={{ style }} at build time, but I don't like adding more setup to my setup, especially if I don't always have access to the setup. Other ideas are welcome
• I had to struggle a lot with typing, especially when I saw that defaultProps are deprecated and I had to create wrapper components around styled components. Seems like types are going to be improved, but other discussions about some default attributes are still valid (for example, this one)
• seems like the project needs more contributors, sometimes this repo feels dead, as nothing happens in discussions, issues, or PRs. This makes me think whether I want to invest more into component library that uses potentially dead library or I should switch it

[peduarte]

@LexSwed Hey, thanks for taking the time to share this. I love it! <3

To address some of your points:

is not a solution as it creates a new object on every render.

It's the type of things that would need to be benchmarked to really know how much of an impact it is - I cant imagine it being an issue.

So I exposed StylesRecord type to ease the writing of custom css objects outside React render cycle

Good idea to the concern above. We'll offer a type helper for this too.

Sometimes I feel that exposing css prop is useless, people can just create own components using styled

There's a significant need to expose the css prop to allow people to set layout-related properties, overrides, and any CSS they wish, like pseudo elements, descendant selectors etc. At Modulz, we rely on this prop a lot. It's extremely helpful for when extending other components.

A solution to this could be a babel plugin similar emotion one to extract inline css={{ style }} at build time, but I don't like adding more setup to my setup, especially if I don't always have access to the setup.

This on the cards, and we may very well offer a build time version of Stitches. But we'll see.

I had to struggle a lot with typing

As you've discovered, there are lots of typing improvements coming out soon. We've also recently (0.0.3-canary.4) released two helpful types StitchesProps and StitchesVariants to extract props/variants from Stitches components.

seems like the project needs more contributors, sometimes this repo feels dead, as nothing happens in discussions, issues, or PRs.

I think as Stitches becomes more popular, the rest will come - I hope 🙂

This makes me think whether I want to invest more into component library that uses potentially dead library or I should switch it

Stitches is not and won't be a dead library. Myself, @jonathantneal and @hadihallak work on Stitches every day. This doesn't mean we push code to this repo every day, some features take days to implement, test, etc. We're also working hard on building a benchmark platform, so we know exactly how well stitches performs and how new features may impact its performance.

If it makes you feel any better, we're currently building the new Design System for Modulz using Stitches. This is a big investment on our part and we wouldn't be doing so unless we knew Stitches was here to stay.

Our current efforts are now into getting Stitches ready for its stable release (v1). So until then, things are still in motion. APIs may break, features may be removed/added, etc. So at this point, I believe things are going to plan and I wouldn't expect too many contributors until its stable. Having said that, though, we have had quite a fair bit of contributors, way more than I imagined! 😄

I'm always around on Twitter or Discord if you have any questions about what we're working on or want to provide feedback.

Once again thanks for sharing this, its super helpful for us.

[LexSwed]

Thanks a lot, glad to see you have plans on this 🚀