isomorphic-style-loader icon indicating copy to clipboard operation
isomorphic-style-loader copied to clipboard

Integration with webpack-isomorphic-tools

Open sompylasar opened this issue 9 years ago • 3 comments

I'd like to share my experience using isomorphic-style-loader in a project that uses webpack-isomorphic-tools to convert modules to JS on the server-side, not webpack loaders.

Here are my notes: https://github.com/halt-hammerzeit/webpack-isomorphic-tools/issues/59#issuecomment-202217795

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/32313144-integration-with-webpack-isomorphic-tools?utm_campaign=plugin&utm_content=tracker%2F26439769&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F26439769&utm_medium=issues&utm_source=github).

sompylasar avatar Mar 28 '16 03:03 sompylasar

I can't stress enough how helpful that was for me. Thank you @sompylasar

sergeylukin avatar Apr 01 '16 00:04 sergeylukin

I saw your issue on the webpack-isomorphic-tools repo, thanks a lot for taking the time to write it - it helped a lot.

@sompylasar did you ever manage to get webpack-isomoprhic-tools to use the same parser as isomorphic-style-loader on the server? It would be great if the server-side require call for the css could return the same attributes as on the browser transpiled end.

I'm having a problem at the moment where the client adds the styles to the head again since the server-side rendered css can't be uniquely identified by it's id like on the client.

isaac-peka avatar Apr 05 '16 15:04 isaac-peka

@sampeka No, because:

        // `webpack-isomorphic-tools` does not use `webpack` loaders,
        // it uses its own way to convert assets to JS, called parsers.
        // The parser results are collected and cached in the `webpack-assets.json` file.
        // Usually, we would imitate behavior of loaders for known asset types
        // to provide proper `exports` objects on the server-side.
        // But `isomorphic-style-loader`'s `exports` object exports
        // functions `_getCss` and `_insertCss` which for some reason cannot be
        // serialized into `webpack-assets.json` although in `require-hacker`
        // which is responsible for serialization the CommonJS modules are handled specifically.
        // @see https://github.com/halt-hammerzeit/require-hacker/blob/ccd584d68fb8fee8a117b7ddfe0b2bcaeed309e8/source/require%20hacker.js#L280-L297
        // @see https://github.com/halt-hammerzeit/require-hacker/blob/ccd584d68fb8fee8a117b7ddfe0b2bcaeed309e8/source/require%20hacker.js#L451-L456
        // So we reuse the CSS Modules converter from `webpack-isomorphic-tools`
        // that builds a module that exports the CSS Modules classnames
        // and an additional `_style` string property with raw CSS text.
        // This structure gets serialized properly.
        // @see https://github.com/halt-hammerzeit/webpack-isomorphic-tools/blob/5e468729fe0a59eaed4f8a0f9da5ba92a4a7e3c5/source/plugin/plugin.js#L194-L199

The object with the functions that should be returned from the require call cannot be serialized into webpack-assets.json from which it is served by the webpack-isomorphic-tools's require-hacker upon each server-side require call. I had to use ._style, not ._getCss() in my insertCss function on the server-side -- effectively, it's the same.

I'm having a problem at the moment where the client adds the styles to the head again since the server-side rendered css can't be uniquely identified by it's id like on the client.

I'm probably having that, too, but I haven't had time to discover that and look for a solution (nor I think it is important for now because all the styles are modular, and do not intersect/conflict with each other, do not depend on the order of insertion).

sompylasar avatar Apr 06 '16 00:04 sompylasar