bau css to support SSR?

[illiaChaban]

bau css looks simple and neat. Very similar to how goober does things with reduced complexity.
Any plans to support SSR?
The way goober does it they use "context" object when "window" or "document" is not availalble and then "renderToString" method that basically reads from that context for SSR
Example

[FredericHeem]

bau-css already supports SSR, examples can be found in bausaurus, a Static Site Generator.

[illiaChaban]

@FredericHeem can you clarify how it works?
I see this context creation logic (1, 2) that creates css through BauCss, but it's using "window" and "document" which should only be available in the browser and not on the server. Are you using some kind of mock for those global objects? I can't figure out how css is supposed to be hydrated on the server in this case

[FredericHeem]

"window" and "document" are mocked by jsdom

bau/bausaurus/src/server/renderPage.js

Line 158 in 7149d9c

const dom = createJSDOM();

Then feeded into createContext:

const context = createContext({
      window: dom.window,
      config: { base: viteConfig.base },
    });

[illiaChaban]

@FredericHeem thanks. Makes sense. I wonder if adding this SSR example to bau-css readme could be helpful.

Another question, I see that it adds "style" element for each classname with a matching class id and then uses that to check if the styles were already added in the future. I wonder if it would be better for bundle size during SSR to use one style tag for all styles (i.e <style id="bau-css" >) and use smth like JS Set or object ({bau1323: 1, bau2342: 1}) to keep track of added classes. I feel like it may reduce html bundle size since it can avoid duplicating info. On the other hand, it should probably be tested how helpful this is exactly because gzipping can take care of repeating strings like <style id="..."> so it might not make a big difference

[louwers]

Maybe splitting the SSR part into a separate package would be a good idea.