Atomic generator

[behnammodi]

We generate a lot of common style somethings like this:

.a1-0-1-105 {
  display: none;
}

.a2-0-1-106 {
  display: none;
}

And style sheet size is increasing in a large project

We can use an atomic style generator, Some of the libraries did it like:

https://github.com/robinweser/fela

And

https://github.com/styletron/styletron

Are you willing to implement it? Yes

[kof]

We discussed this thing a bit, there are certain downsides coming with atomic approach, but I encourage you to create an AtomicDomRenderer that would render out the rules in an atomic way (one css rule - one property).

See DomRenderer for the current rendering implementation example.

[behnammodi]

@kof Thank you, I will try to do that, but maybe somewhere I need your help

[behnammodi]

@kof Hi man, I investigate the entire project to create an Atomic generator, I think we need a new class of BaseStyleRule for that.

That is right?

[kof]

I was hoping its possible to do by just supplying a different DomRenderer implementation, without modifying antything else, renderer can be passed to Jss as an option.

Or alternatively, which is eventually a simpler option, but would not work with vanilla JSS and not with any other integrations and would require to fork react-jss - creating a new rule per property from createUseStyles.

[behnammodi]

I will investigate more about DomRenderer.

[behnammodi]

I hard worked on DomRenderer, so I have to say it not possible to have Atomic Generator just by changing DomRenderer

I think this future is very important because the new approach of CSS in JS is about Atomic generation. I could find a new repo about that: https://github.com/johanholmerin/style9

and a video of Facebook on youtube about CSS in JS: https://www.youtube.com/watch?v=9JZHodNR184

[kof]

Can you show me what you did and what was impossible?

Regarding atomic - it's absolutely not new. It's been originally in react-native-web, then they migrated to partially using regular rules and partially atomic. There is fela and a bunch of others which do atomic. There is a number of downsides on this approach and it should be up to the user what they choose. What I am saying is that it's not a new trend but still a good thing to have as an option.

[behnammodi]

@kof I said it not possible by DomRenderer

We need to compute on Rule before giving it to DomRenderer. I create a flow for that, so we have to have a process like this:

So we need these green boxes

[behnammodi]

Woo, I found new one :)

https://stitches.dev/

[kof]

Stitches just recently switched from atomic to regular rules.

[behnammodi]

Stitches just recently switched from atomic to regular rules.

Why? have they any notes about that?

[kof]

I haven't found any, feel free to ask them.

[behnammodi]

I haven't found any, feel free to ask them.

Ok, did you see my process flow?

[kof]

I think the biggest problem here is classes map, because we currently create a class name per jss rule, but if we were to render it to multiple css rules, each jss rule would need a new class and they would have to land in classes something like this: classes = {myButton: 'a b c d'}.

We have a way to pass a custom id generator to jss, it's createGenerateId function (just in case). But it's designed around a single rule and is being called in StyleRule and KeyframesRule.

So it seems you would need 3 things:

1. create class name for the atomic rule
2. ability to register a compound class name in sheet.classes
3. make sure that atomic rules from media queries are not mixed up with the global once, because inside media query they can only be reused between rules of the same media query

What else am I missing?

[behnammodi]

Now nothing, may in the implementation phase we have another concern

[kof]

Maybe a combination of a AtomicDomRenderer and a plugin that uses the hooks api could do the job.

[behnammodi]

But I think we have to forget AtomicDomRenderer and focusing on AtomicStyleSheet