Support customization "Custom styles" without cloning the repo

[gasparnagy]

🤔 What's the problem you're trying to solve?

With #409 we have introduced providing custom additional CSS and Javascript.

The custom CSS is great for "theming" and it works. 🎉

Changing the style of a particular kind of component (described as "Custom styles
" at react-components) however is not possible with custom css, because there are generated CSS class names on the elements.

The example in react-components shows a solution using the <CustomRendering> object, but for that one would need to setup a clone of this repo and make an custom node.js app to generate the source.

In this particular case, the object provided for the <CustomRendering> override is a plain Javascript object:

{
  DocString: {
    docString: 'acme-docstring'
  }
}

So we could allow somehow to specify this as a customization.

✨ What's your proposed solution?

We haven't found one obvious solution, so more input is needed. (@davidjgoss ?)

What we considered:

1. Somehow make it customizable through the mustache template: have a template placeholder {{rendering_override}} (?) that is by default initialized with empty string or empty json object and either always have the <CustomRendering> wrapper or somehow make the main.tsx decide if the wrapper is needed.
2. Make it customizable in a custom script block. E.g. if a custom script block sets window.customRenderingOverride then we wrap the code with <CustomRendering> and use it.

It is not directly related to this, but it would be useful if the React root object and the loaded cucumber react-component namespace would be available in the window object, so that custom scripts can access it.

⛏ Have you considered any alternatives or workarounds?

The alternative is to clone the javascript folder of this repo as an own node.js project and replicate the webpack build process. This would work, but seems to be an overkill for a simple styling (and makes it harder to adopt changes from this repo, e.g. when styles.scss changes).

📚 Any additional context?

I try to capture our discussion with @mpkorstanje today in this issue, so that we don't forget.

[davidjgoss]

I think of the two options, no1 looks cleaner on the face of it, but no2 will be much more useful to users even though it's a bit messy to have things on the global object. Being able to set it from their custom JS means they could even go as far as adding custom React component overrides if they want.

I would follow the pattern we've done with messages and call the property like window.CUCUMBER_CUSTOM_RENDERING_OVERRIDES just to minimise any collisions.

The only other thing I'd add is, with #283 which I'm working on again now, there will be new components to target and some existing ones will become defunct. That'll all be in a major semver revision though.

[gasparnagy]

The only other thing I'd add is, with #283 which I'm working on again now, there will be new components to target and some existing ones will become defunct. That'll all be in a major semver revision though.

This is not a problem. I think it is absolutely fine to wait for #283 first and only after deal with this.