Last 12 weeks · 0 commits
4 of 6 standards met
code-1: const divClass = css; code-2: const divClass = css; place ':hover' before or after ':not(.active)' can lead different result. result-1: .go111111111>span:hover:not(.active){cursor:pointer;} this is right. result-2: .go111111111>span:not(.active).go111111111 :hover{cursor:pointer;} this is obviously wrong.
Repository: solidjs/solid-styled-components. Description: A 1kb Styled Components library for Solid Stars: 296, Forks: 24. Primary language: TypeScript. Languages: TypeScript (56.8%), JavaScript (43.2%). License: MIT. Open PRs: 2, open issues: 29. Last activity: 1y ago. Community health: 75%. Top contributors: ryansolid, btakita, SogoCZE, kocheshkov, Asha20, diragb, 100terres, jay-es, RealPeha, Jarvis1010.
As there is no discussion tab in this repo, I think an issue would be appropriate. Goober may be very small, having CSS in JS in 1kb gzipped is amazing, but it may not be good to use in big projects. In andreipfeiffer's CSS in JS Goober Analysis he mentions how inefficient Goober can be for dynamic styles. Not only that but Goober does not allow Atomic CSS, when an update is made to the stylesheet, not only it seems to duplicate, but it seems to duplicate the whole rule, even for things that haven't been changed at all. Here is a CodeSandbox sample that demonstrates this behaviour. The 1kb promise may look good to the eyes, but I think that behind there's a very unoptimized library that in the end, suffers from being optimized as it is only 1kb. How easy would it be to replace Goober in the internals of Solid-Styled-Components? Has anyone built something in production with SSC that's scalable? There's some examples that I can give of alternatives to CSS in JS but I would like to first hear your opinion about it.