SDK: use higher level component to scope styles for Calypso components

[simison]

Based on the previous experiment to scope our CSS (#26683). This has a bunch of code from that other PR to namespace styles needed for this experiment.

This automates the other part — injecting the scope CSS selector in components.

Instead of manually adding .calypso to the block's code, we could add a wrapper component that only adds the scope CSS selector to the component. This would require ensuring each component in Calypso does something like this:

import calypsoComponent from 'lib/sdk';
class Card extends React.Component {
  // ...
}
export default calypsoComponent( Card );

Higher order component would be shipped together with blocks and applied in run-time.

Input:

const edit = ( { className } ) => (
	<Card className={ className }>
		<Ribbon>Hidden</Ribbon>
	</Card>
);

Output:

<div class="wp-block-a8c-editor-notes card calypso">
  <div class="ribbon">
    <span class="ribbon__title">Hidden</span>
  </div>
</div>

We can now use scoped CSS that applies only to Calypso components:

.calypso .card {
  border-color: red;
}

Problems

• Applied in run time
• Requires changes to all components in Calypso
• In this example, block outputs html: <div class="card calypso"></div> but CSS is .calypso .card {} — note the space in between. HTML would need to be <div class="calypso"><div class="card"></div></div> for this to work. That can be solved by wrapping the component in additional <div> at the higher level component.

Testing

1. Build

npm run sdk:gutenberg -- --editor-script=client/gutenberg/extensions/editor-notes/index.js

2. Grab files from client/gutenberg/extensions/editor-notes/build and load them in Gutenberg.

3. Observe the Card element has calypso class in it

[matticbot]

Test live: https://calypso.live/?branch=try/sdk-scoping-with-higher-level-component

[ockham]

Problems

• Applied in run time
• Requires changes to all components in Calypso

See my comment on pa9srA-l-p2:

In terms of developer experience, I’d personally like to rule out anything that requires the developer to manually add a scope class — and that includes wrapping components in an HoC that provides that kind of class. (Rationale — this is something a dev shouldn’t simply have to worry about when writing a component, and requiring this kind of manual wrapping is probably easy to miss and thus fragile.)