
Stitches
Style your components with confidence
CSS-in-JS with near-zero runtime, SSR, multi-variant support, and a best-in-class developer experience.
Stitches Core
Framework-agnostic implementation.
npm install @stitches/core
Stitches React
React wrapper including the styled
API.
npm install @stitches/react
Documentation
For full documentation, visit stitches.dev.
Contributing
Please follow our contributing guidelines.
Community
You can join the Stitches Discord to chat with other members of the community.
Here's a list of community-built projects:
Authors
- Pedro Duarte (@peduarte) - Modulz
- Jonathan Neal (@jon_neal) - Modulz
- Abdulhadi Alhallak (@hadi_hlk) - Modulz
License
Licensed under the MIT License, Copyright © 2021-present Modulz.
See LICENSE for more information.
[Feature] Dynamic variants
This introduces a new set of features in stitches called dynamic variants.
The purpose of this is to allow dynamic props to apply CSS values at static, server, and client-side.
Example of dynamic spacer component.
React native support
I really love what you guys have been doing with stitches and have been loving it so far!
Any idea if react native is in the roadmap, I think the community would benefit a lot from this
Media queries inside variants
We need to be able to place media queries inside a variant block.
This is possible in all popular css-in-js libs and preprocessors.
Without it, styling components becomes unmaintainable.
This may be related to #79.
Incorrect style order
Bug report
Description
Styles are applied in incorrect order depending on how styled component are composed.
Things get even more unpredictable when using Foo & Bar on the same view. Depending on the order of Foo & Bar the styles might or might not apply correctly, see reproduction below.
To Reproduce
Expected behavior
When using
styled(Foo, styleObject)
, rules defined instyleObject
should overrideFoo
's existing styles.System information
'length' is declared here
Bug report
Describe the bug
createStitches
styled
method requireslength
field to be set.length
is part ofString
object.To Reproduce
Expected behavior
Not to have to enter
length
.System information
:hover and :active specificity issue
When trying to add
:hover
and:active
pseudo states in CSS, we'd usually do:This is so when you mousedown while hovered, the
:active
style takes precedence.Adding the same rules, in the same order, in Stitches (running in CRA), yields unexpected result.
Repro: https://codesandbox.io/s/stitches-hoveractive-states-sezl2?file=/src/App.tsx:177-259
In the Codesandbox above, notice how when you mousedown the background color remains red. It should change to blue.
Out of curiosity, I tried to do the same with SSR (Next.js), and the SSR generated styles works as expected 😄
SSR Demo: https://codesandbox.io/s/stitches-hoveractive-states-with-ssr-lyc6f?file=/pages/index.js
Add support for custom (human-friendly) class names
Taking a stab at a different API to this, based on feedback in #916 (see details there).
(Addresses #650)
Proposed API
Users can use a
withName
utility method to pass in a string as the custom component name, with their calls tostyled
, like so:This proposed solution could be combined with a babel plugin, to make friendly class names possible with no extra effort, for those using Babel.
The existing syntax would be unchanged, plus this approach works just as well with
css.withName("Xyz")(...)
, so it's not limited to React only.I feel that this functionality makes debugging much, much easier, so would love to work with the core team to find the right API to get this into production ❤️ .
SolidJS package
This closes #818
This package package is 98% copy paste from @stitches/react with some typing changes + a
styled.js
implementation. I'm fairly certain we could share types better between these two packages but not sure if that needs to be done right away.This PR isn't ready to merge yet, I need to update tests for solid but wanted to get the conversation going to see if I should press forward.
React.ComponentProps not working as expected
Bug report
Describe the bug
When wanting to get the type of the props a stitches component receives, for example to be able to compose other components on top of it,
React.ComponentProps<typeof StitchesComponent>
is not working as expected — it's signaling weird errors and not providing correct typings. More context in this discussion.To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:
<LoadingButton />
.<LoadingButton />
has type errors. (propertyas
is required).Expected behavior
I expected LoadingButton to be error free with the props provided, and for prop suggestions to be button-specific.
Screenshots
IE11 support without Proxy, alternative API, and feedback
Hey there,
I was checking the code and it uses
Proxy
which doesn't have IE11 support. I initially thought that maybe I could use aProxy
polyfill. However, this kind of polyfills require to know all properties at the time theProxy
is created which isn't possible here.Would you consider also an alternative (additional) API? Something more close to CSS-in-JS syntax? For example:
Here
button
andalternative
are equivalent. It's closer to CSS and it doesn't really require a Proxy to know which are utility or css props, for instance. It's also fairly easy to type in TS.A working example of the above:
Then you can:
Of course, this is an abstraction on top of the current implementation that uses Proxy but it's just to demonstrate that it could also work with an alternative (additional) API closer to CSS-in-JS object syntax (and it'd work in IE11 🙈)
Deprecate `defaultVariants` in favour of `props` and `defaultProps`
After a long discussion internally and with many of our users, we've decided to allow users to create default props when creating a Stitches Component.
Reasons:
As a result, we'll rename
defaultVariants
todefaultProps
, for the following reasons:defaultProps
defaultVariants
)Additionally, there seems to be a lot of confusion around the fact that
defaultVariants
get inherited by compositions. This breaks most people expectations. There's an issue for it here https://github.com/modulz/stitches/issues/686.By renaming from
defaultVariants
todefaultProps
we believe it'll make it clearer that the props will not be carried over - since each component can have different responsibilities and different type, meaning attributes have to be dependant on its type.This would also allow people to define an
as
prop. Would this be problematic in terms of types?For example:
About polymorphism, we need to understand how much this will stall the TS engine.
Another solution to keep in mind, is to prevent the
as
prop indefaultProps
, and instead force it to be defined as the type (1st argument)Are there any pros and cons?
UPDATE:
After some thought, I think the right course of action is to
restrict the usage of
asin
defauultProps`.It creates too many layers of polymorphism, and requires a lot of mental model to understand what's going on. Additionally, it opens up many doors to complex and confusing architecture.
The idea here is that the
as
prop is only available on components returned bystyled()
.UPDATE 2:
After even more thoughts, chats, and calls, we've arrived at the following conclusion:
styled
function (this is something supported by allstyled()
-like APIs, so it makes sense we support it too, for better interoperability and hopefully more users wanting to migrate over - with more ease)So if we consider this for a moment, I think we could make this work with the following objects:
props
: your component will be initialised with these props and they will not carry over to compositionsdefaultProps
: your component will be initialised with these props and they will carry over to compositionsSo, the actions for this issue are:
defaultVariants
props
object: the component will be initialised with this, and this will not get carried over to compositionsdefaultProps
object: the component will be initialised with this, and this will get carried over to compositionsas
key is not allowed inprops
anddefaultProps
Variants which contain numeric strings (e.g. "-12") and number keys (e.g. 12) are assigned a 'number' type when generating a union using the VariantProps type
Let's say I create a component with a variant called 'margin', which has a mix of numeric and numeric string keys, like so:
I would expect, if I then passed
StyledBox
to Stitches.VariantProps (e.g.Stitches.VariantProps<typeof StyledBox>
), the following type would be generated considering that the keys are both technically numeric:However, the following type is generated, which contains the 'number' type:
Naturally this is not ideal for strong typing as any number can be accepted as a variant key. However, interestingly, if I change the variant negative key (e.g. "-12") to a non numeric string (e.g. "neg12") the types are correct/how I would want them in my first example. For example:
And the correctly generated types:
This is not a big issue as I can just change any numeric strings (e.g. "-12") to non-numeric strings (e.g. "neg12") in my variant keys, but I hope it's something that can be fixed in the future.
Stitches version: 1.2.8
Token from theme object not assignable to util
Bug report
When trying to use utils in combination with tokens from
theme
I get a ts error.Describe the bug
Due to the lack of information on this topic in docs, along with inability to solve it with neither
PropertyValue
norScaleValue
and missing export of appropriate type, I assume this might be a bug.System information
Page becomes unresponsive when using multiple custom stitches components
Bug report
Describe the bug
I created a sandbox with React + Typescript + Stitches. I created some basic components like
Box
andText
with stitches, something like belowWhen I am using the above components my page is
freezing
andno UI
is renderedTo Reproduce
Steps to reproduce the behavior:
blank
Steps to see the preview section
Expected behavior
When using stitches components should not freeze my page.
Screenshots
Firefox
System information
Additional context
not working from next.js 13 & need server side supports for next.js 13
Bug report
I tried on next.js 13 app dir and it seems styling is not working.
I read the issue below and found couple of answers to figure it out example:
#1109
but still not working for me (even from client side). Any solutions suggested?
In a grid layout, gap configured in breakpoints won't work
Bug report
Describe the bug
When writing a stitches object, the grid column/row object won't apply on the element.
To Reproduce
The object looks like this:
Expected behavior
Expected that the gap will be applied based on different breakpoint.
Screenshots
System information
(Feature request): good name of components generated by stitches inside react dev tools
Hi stiches team,
is there a way that generated stitches components get the right component name inside react developper tools ? It's quite hard to read inside the react chrome inspector. In the examples bellow i would like to see
ScrollableContent
instead ofStyled.div
inside the react chrome inspector