Support scoped CSS in the same file

@jquense

This is kinda vague but I'd like to have a built-in option to write CSS that:

Exists in the same file as my components
Is scoped
Has auto generated class names, like CSS Modules
Extracted via the same pipeline as CSS Modules
Could potentially use Sass (since we already support it)
Fully static

Basically I want "CSS Modules" but without the "Modules" part. Just put it in the same file if that's the only place I use it anyway.

https://github.com/4Catalyzer/astroturf looks related. cc @jquense @markdalgleish

Would this be like opening a style tag in .vue single file components? I think it'd be a great addition

Also relevant: https://github.com/callstack/linaria

Would this be like opening a style tag in .vue single file components?

Yeah. Except I don't want to partition file into sections like Vue does. Keep it JS but add the ability to add CSS styles inside.

This sounds a bit like styled-jsx.

TBH I think astroturf covers all these points, at it's core it's co-locating CSS files in JS. It's actually implemented as that; the tag content is extracted to a CSS file (not written to disk via webpack magic). The really nice thing about this approach is you get ALL the benefits of writing separate files without the work. For instance mini-extraxt-css-plugin and html-plugin both automatically works without any additional setup.

We've got all the relevant standalone loaders, plugins and Babel plugins in repo, you could integrate with a global css tag with all the library details hidden.

We've been using this for all our large projects with Sass and its really hit a nice sweet spot for convenient component API and playing nice with the tons of existing CSS tooling

@ai

I will say css-modules can be wonky and weird but if you're using them, I think the inline approach is really an ergonomic improvement. Cc @ai too

an astroturf macro would be nice to start playing with this in CRA right now. it appears astroturf has a babel plugin already, so making a macro version shouldn't be too hard?

It would be great to treat CSS as a first-class citizen in ReactJS!

linaria is a nice project, but right now I prefer astroturf, because of more high order API:

styled to created React component like in styled-component.
Syntax sugar for modifiers: &.primary then can be used as <Button primary>.
Syntax sugar for keyframes. You can write them in the same styled declaration and they still will be scoped.

@jquense

@jquense just a question, looking at astroturf repo I didn't find that. That's an way to create a local class, like :local from css-modules does?

@threepointone

@threepointone

The macro should be easy enough since the core is a babel-plugin, tho i'm not sure how'd deal we the extracted css files, they'd need to be written to disk somewhere. In a webpack env tho the loader avoids this by using a virtual filesystem plugin, exposes the files only to webpack's fs

@renatoagds astroturf is css-modules, so the behavior is the same, we have :local by default on since that's what css-loader does by default, so all classes are scoped. you can use :global to create global ones instead

Yup – so the contrast here is that astroturf just handles pulling out the CSS into a separate virtual file, without imposing any of its own opinions on how to do CSS processing. It fully uses the existing CSS processing pipeline, which means that if you have Sass set up, then it will run Sass on your styling code – and this is exactly how we use it.

Do we have anyone that use astroturf in production ? To share the pros and cons using it.

We use astroturf in production right now.

For the part of the API as described above, there's not really any "experience". The whole point is that it doesn't do anything at runtime – it just pulls the CSS out into a separate file, and lets the rest of your pipeline take over.

The experience analogous to defining a CSS module next to my JavaScript, just without having to go bother with having a separate file.

@renatoagds

@renatoagds I am using it in production. I use both css and styled function in big React. I converted the project from Emotion.js to astroturf in a few days (mostly because of our auto-import hacks). Animation, many custom PostCSS plugins, webpack CSS minification — everything work. Compare to Emotion we even fix few issues and reduce code size (thanks to &.modifier and @keyframes syntax sugar).

The only problem is that Stylelint doesn’t support it right now. But I created an issue and fix is very simple.

@giuseppeg

@giuseppeg

Toggling class names based on props or using inline styles is far better and more efficient.

Why is that more efficient than CSS variables?

Has anybody ever made a comparison table between Linaria and Astroturf

This only lists advantages of Linaria, but it's a start:

astroturfcss/astroturf#69 (comment)

@satya164

@satya164 yeah for theming custom properties are the best. Not sure how I feel about conditional styles and more complex things. Some use props to define sets of declarations (within a rule) conditionally or do crazy things with them.

I've got a WIP for getting Linaria dynamic props working on IE.

See callstack/linaria#446

@satya164

@satya164 indeed I would lean towards Linaria (I guess mainly for the composition capabilities).

The only thing I dislike about it is the fact that it uses Stylis for preprocessing. I love Stylis but PostCSS is superior and less flacky. For build time solutions I'd pick PostCSS also because it supports plugins.

FWIW if you only use props/custom properties for theming I wouldn't bother supporting IE11. I would just add a fallback and provide a single default theme (that's how I do at work).

FWIW(2) https://github.com/threepointone/glam tried to implement a polyfill for IE11.

FWIW if you only use props/custom properties for theming I wouldn't bother supporting IE11. I would just add a fallback and provide a single default theme (that's how I do at work).

How would you add a fallback cleanly?

with this plugin https://github.com/postcss/postcss-custom-properties

@giuseppeg

@giuseppeg

The only thing I dislike about it is the fact that it uses Stylis for preprocessing. I love Stylis but PostCSS is superior and less flacky.

It does use stylis by default. But the preprocessor is customizable: https://github.com/callstack/linaria/blob/master/docs/BUNDLERS_INTEGRATION.md#options

@giuseppeg

Some use props to define sets of declarations (within a rule) conditionally.

@giuseppeg can you please explain why this is a bad thing or how it's less efficient? @satya164 what will Linaria do "under the hood" if one attempts to do something like this? Will a class be created for the condition?

const Foo = styled.div`
  color: black;
  ${props => props.error && {
    color: red;
    border: 1px solid red;
  }}
`

There's probably something wrong with my syntax.

It does use stylis by default. But the preprocessor is customizable: https://github.com/callstack/linaria/blob/master/docs/BUNDLERS_INTEGRATION.md#options

To be clear, @satya164, this means you can configure Linaria to use PostCSS as a preprocessor?

@jedmao

@jedmao every time the prop evaluates to a different value the css in js library has to generate a new css rule and inject it in the stylesheet. So even though part of that rule is static (in your example color: black) you end up not reusing it.

And to clarify if you have a highly dynamic application (RTL, theming etc) probably doing these at runtime is way better, my point was that the more you can reuse (compose) the better but of course libraries cache aggressively and for many this is not a big deal!

That color: black declaration, should it be duplicated, would not add any real footprint after gzip, FWIW. But I see your point, if that's indeed how it (Linaria) works under the hood.

I don't see the composition issue though. I've used BEM successfully before with ultimate composition, but I don't think I would lose composition with CSS in JS.

@jedmao

@jedmao currently Linaria only supports interpolations for property values.

const Foo = styled.div`
  color: ${props => props.primary  ? 'blue' : 'black'}
`;

Internally it converts interpolations to CSS variables whose values are updated with the style property on the component.

this means you can configure Linaria to use PostCSS as a preprocessor

Yes

I just published a craco plugin for Linaria, for those who don't want to eject from CRA, but still want CSS in JS.

Is there any news on using astroturf with CRA without ejecting at this point? (other than the above mentioned craco plugin for Linaria)

Navigation Menu

Repository navigation

Support scoped CSS in the same file #5224

59 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support scoped CSS in the same file #5224

Description

Activity

lucassartori94 commented on Oct 2, 2018

gaearon commented on Oct 2, 2018

Timer commented on Oct 2, 2018

jquense commented on Oct 2, 2018

jquense commented on Oct 2, 2018

threepointone commented on Oct 2, 2018

kdekooter commented on Oct 2, 2018

ai commented on Oct 2, 2018

renatoagds commented on Oct 2, 2018

jquense commented on Oct 2, 2018

taion commented on Oct 2, 2018

renatoagds commented on Oct 2, 2018

taion commented on Oct 2, 2018

ai commented on Oct 2, 2018

59 remaining items

satya164 commented on Jul 3, 2019

giuseppeg commented on Jul 3, 2019

nhooyr commented on Jul 3, 2019

giuseppeg commented on Jul 3, 2019

giuseppeg commented on Jul 3, 2019

giuseppeg commented on Jul 3, 2019

nhooyr commented on Jul 3, 2019

giuseppeg commented on Jul 3, 2019

satya164 commented on Jul 3, 2019

jednano commented on Jul 3, 2019

giuseppeg commented on Jul 3, 2019

jednano commented on Jul 3, 2019

satya164 commented on Jul 4, 2019

jednano commented on Aug 27, 2019

darthdeus commented on May 12, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions