summary

There are many tradeoffs to weigh when thinking about how to use jss/react-jss with preact-based amp components.
This PR gets us out of a weird half done stage using the naive approach, although I personally think the "compiled" approach makes more sense long term and I'd like to discuss that.

Naive method: using libraries as-is
The most naive way of using the two libraries means using them at runtime. For lightdom, the default location of document.head as the insertion point for the <style> tag is fine, but for shadow dom (amp mode) we have to specify our own insertionPoint. The useStyles hook in react-jss will grab the nearest jss instance in Context, so we can pretty easily customize insertion point.

Pros:

• Simplest option
• Consumers of the individual preact components can provide their own jss instances to customize the outputted css

Cons:

• bundle size: jss is 22kb and react-jss is 42kb
• performance cost associated with the size

Compiled

We use the JSS format and library only at compile time in order to create standard css files.
We then ship each preact component with a separate css file. This would be trivial to include in amp mode, as well as for consumers of individual bento amp components.

Within the ecosystem, it is also relatively common for components to ship css files that must be manually included, for example the popular date picker library, react-dates that we already use in AMP.

Pros:

• Removes all associated unnecessary bundle/performance cost.

Cons:

• requires build-step integration for consumers looking to customize the css (e.g. by running through PostCSS)
• an extra step for devs to include the required css