Add an option to output atomic css

Do you want to request a feature or report a bug? Feature

What is the current behavior?

If the current behavior is a bug, please provide the steps to reproduce and a minimal repository on GitHub that we can yarn install and yarn test.

What is the expected behavior? The current behavior is

// Input 

const header = css`
  text-transform: uppercase;
  font-family: ${fonts.heading};
  font-size: ${modularScale(2)};
`;

// Current Output
const header = 'header_t1ugh8t9';

// Expected Output
const header = 'tt_swer3 ff_Sers34 fs_5tsdf';
/*
tt_swer3  -> text-transform
ff_Sers34 -> font-family
fs_5tsdf -> font-size
*/

Please provide your exact Babel configuration and mention your Linaria, Node, Yarn/npm version and operating system.

[jpnelson]

This is a really interesting discussion – I’ve done a bit of a prototyping into what would be required for supporting this in Linaria – it’d be a fairly different implementation, but we could keep a similar API shape (not too dissimilar from css-zero ). At a high level, what I’d suggest would be something like this in React:

import { css, styled } from '@linaria/atomic';

const blue = css`
   color: blue;
`;

const Component = styled.div`
  color: blue;
  border: 1px solid black;
`;

export default function () {
  return <Component>
    <p className="blue">Hello</p>
  </Component>
}

which would produce:

<div class="atm_foo123">
  <p class="atm_foo123 atm_bar456">
    Hello
  </p>
</div>

.atm_foo123 {
  color: blue;
}
.atm_bar456 {
  border: 1px solid black;
}

To get there we’d need:

• A @linaria/atomic package, that contains the new API (note: we’d probably also want new stylelint rules to enforce the fact that nesting / cascading isn’t allowed in atomic css)
• Support in the babel plugin for the atomic logic in this new API
• The collect utility from @linaria/server to support sorting / deduping these atomic rules (I think prefixing them with a consistent prefix, eg. atm_ could help here)

For @jayu 's point about deduping the produced rules, I think we dedupe rules at a file level, and rely on the bundler to dedupe those as well in produced css files (so, add webpack support, or similar).

For us, the big advantage of doing this is that the atomic rules don’t depend on declaration order – we can determine which atomic rules to apply at build time. Additionally, the total css size can be reduced.

It’d be a fairly big new addition to the library though – @jayu, if I created a proof of concept along the lines of the above, would you be open to discussing the potential inclusion? I think it’ll end up being a bunch of new work though so it’d be great to hear what your thoughts are for the direction on this going forward.

[LucaColonnello]

I would have loved to see this coming though! So sad to see it has been closed! This is the approach taken by the new Facebook style lib, which would be open source at some point. But I think, considering it seems that lib is quite opinionated in the way to write CSS (ReactNative style), it would be good to see this in Linaria as an opt-in feature.

If I have some time, does anyone mind me spiking it?