Runtime dependency injection

[markdalgleish]

As a module author, I want a standard CSS-in-JS format to allow me to provide my styles agnostic of whatever runtime or UI library the parent app is using.

As a module consumer, I want to be able to collect all the styles provided in my dependency tree and pass them to my runtime of choice.

IMO this is essential if we want to allow people to publish CSS-in-JS without punishing them for picking the wrong library.

Does this sound like a good idea? Do we have any thoughts on how best to achieve this?

[geelen]

What's your boundary of a "module" here? Is it a component or just CSS?

If I was to rephrase, I'd suggest that you'd want to be able to export:

import React from 'react'
import X from 'my-css-in-js-lib'

const Y = X.styledComponentsStyle

export default () => (
  <Y className={X.classNameGenerated} />
)

without needing to include all of my-css-in-js-lib?

I'm assuming you're exporting a React component here, if not then potentially wrapping up a module as a Web Component?

[markdalgleish]

I was thinking low level CSS, no opinions about component binding. The API might surface class names or inline style objects, but your package would bind it to a component, if at all.

[kof]

Can we avoid the need for runtime injection? If module exports styles in a standard format, runtime used by the user should be able to pick it up and render, no? Maybe I don't quite understand the use case @markdalgleish has in mind…

[markdalgleish]

What about nested dependencies? What if a module 4 levels deep wants to render some CSS?

[kof]

I just reread this issue. So the question is how can a UI lib be published with styles in ISTF format and be able to render them using a CSSinJS library chosen by the consumer. Without having opinions on the rendering process.

[kof]

That is a tough one. If we have only static CSS, that would mean library just has to accept classes hashes.

In our case we already agreed we want to support dynamic capabilities of CSSinJS, which is the most important property of CSSinJS, it becomes much harder.

Lets assume we are publishing a material-ui library built with SC. I assume we are able to convert CSS strings and replace them with ISTF inline, right where they are. Still it means that in order to render a button from this library I still need to bundle SC. It would be of course a SC version without CSS parser bundled, but still a quite heavy weight library.

Thoughts @philpl ?

[kof]

I guess when someone is publishing to npm, should be carefully consider what to use, for e.g. if styled-components then no-parser version or something.

Mb we need some minimal spec for API which can be relied upon when publishing to NPM. So that it can be easily replaced when needed.

[kof]

Through coupling of styles with components, SC and similar libs are harder to support in a universal way.