Component stylesheet support

[mpeterdev]

I've been kicking around an idea for how we might support a more vanilla CSS workflow. Essentially, can we support saving a stylesheet alongside component source?

Two main hurdles:

1. scoping the CSS to the component when it is hoisted to the OWA
2. identifying anything in the CSS spec which may cause undesirable inter-component interference (this may be the same as with CSS-in-JS)

Potential solution

Alongside component src, the compiler provides the CSS saved on chain which is wrapped in a selector by the OWA such that the rules only apply to descendants of that component on the rendered DOM.

Example

Component: michaelpeter.near/widget/HelloWorld

Source

return <div><span>Hello</span> World</div>;

Currently in BWE, this yields visible DOM of

<div id="dom-michaelpeter.near/widget/HelloWorld" class="container-child">
  <div>
    <span>Hello</span> World
  </div>
</div>

So now let's say we have a stylesheet saved alongside the component source on chain which is the following:

span {
  color: red;
}

We would convert that to something suitable for being injected on the OWA, like so

#dom-michaelpeter\.near\/widget\/HelloWorld {
  all: initial;

  & span {
    color: red;
  }
}

The process is pretty straightforward— we apply an id selector wrapper, then prefix every rule with & to make it a descendant selector (& docs)

Note that we would need to inject the all: initial for every component, even those that don't supply stylesheets, since that is what prevents inheritance of any styles from components higher in the tree

Eager to hear thoughts on if there is anything CSS-wise I am missing which might make this impractical or infeasible

[calebjacob]

Great writeup. I'd love to see this implemented! For the current VM, we mostly use Styled Components for CSS. However, the current implementation has performance issues since we're forced to define the Styled Components inside of the component function body.

This would be the proper way of using Styled Components in a typical React app:

const MyStyledDiv = styled.div`
  color: red;
`;

const MyComponent = () => {
  return <MyStyledDiv />;
};

But the current VM implementation forces us into implementing it like so:

const MyComponent = () => {
  const MyStyledDiv = styled.div`
    color: red;
  `;

  return <MyStyledDiv />;
};

You'll see all kinds of warnings and errors related to this non-standard use of Styled Components when running the current gateway locally. It also causes performance issues since these Styled Components are forced to re-initialize every render.

Your proposal would be a great alternative that's simpler to use for most developers and avoids the performance issues I outlined with Styled Components.

I have a question about how you're currently rendering this id attribute for every component:

<div id="dom-michaelpeter.near/widget/HelloWorld" class="container-child">
  <div>
    <span>Hello</span> World
  </div>
</div>

HTML id's need to be unique across all elements on the page - how do you handle when the same component is rendered more than once? You would need some way of making the id unique. I wonder if it would make more sense to use something like data-component="dom-michaelpeter.near/widget/HelloWorld" instead of using an id?

[mpeterdev]

good eye. Component IDs are formed by concatenating all of the ancestor component IDs, and there is a requirement of BWE that if you use the same component multiple times at the same level—which would result in duplicate IDs—then you must provide an explicit ID for each

More details here: https://github.com/near/bos-web-engine/blob/main/components.md#component-ids

[mpeterdev]

On the note of styled-components and re-initialization: We definitely still want to support styled-components in BWE so this would simply be another option. With our conversation on arbitrary dependencies leading us towards defining the full component module instead of just the function body, we may be able to have styled-components also defined outside of the component as theyre supposed to be

[andy-haynes]

I like this approach a lot, but I do wonder to what extent it's a stopgap for styled components. Do we expect this to be a reasonable alternative even after styled components are available? Can we see a use case where it's used in conjunction with styled components?

Also once that CSS is on chain it may be difficult to stop supporting this in the future, potentially exacerbating schema/architecture changes down the line. Will we always need to check if Components have this CSS document at fetch time? If so then we'd need to keep checking on every fetch until we could deprecate this.

Eager to hear thoughts on if there is anything CSS-wise I am missing which might make this impractical or infeasible

This might be getting too far into implementation details, but is the goal to build a stylesheet for an entire Component tree or inline the styles on individual Components at render time? The former seems like the better performance option but I don't know how that would actually work, while the latter seems like it would interfere with a future styled components implementation.

[mpeterdev]

Do we expect this to be a reasonable alternative even after styled components are available?

I think there will always be developers who are interested in a typical CSS workflow instead of CSS-in-JS, but I wouldn't expect it to be a dealbreaker for a large number of them. It would be nice to support both in the long run if there is no downside

Will we always need to check if Components have this CSS document at fetch time?

I am not following the concern here, we can grab src and styles in a single SocialDB fetch so it would just be a matter of using the CSS if its in the response

is the goal to build a stylesheet for an entire Component tree or inline the styles on individual Components at render time?

We would be adding stylesheets to the page on the fly, and each container would get their own. I am not sure if the proper handling there is appending a <style> element to the page manually or using the document.stylesheets API to manage them

reference: https://developer.mozilla.org/en-US/docs/Web/API/CSS_Object_Model/Using_dynamic_styling_information

[mpeterdev]

I do not believe it is possible to support media queries with inline styles either, so we may find we need an approach like this even with CSS-in-JS

[calebjacob]

I think there will always be developers who are interested in a typical CSS workflow instead of CSS-in-JS, but I wouldn't expect it to be a dealbreaker for a large number of them. It would be nice to support both in the long run if there is no downside

I definitely agree with this. If we can give developers a choice, that's just one more way we can win their trust. There's some really opinionated groups out there when it comes to using vanilla CSS or CSS-in-JS and making both groups feel comfortable would be a big win.

[andy-haynes]

Excellent points on use cases and dev preferences. With both approaches complementing each other and providing value independently, I think this is the way to go.