[Feature request]: More flexible options for ComponentConfig

[isabelacmor]

It would be helpful to allow for some more flexible options for ComponentConfig, so consumers can better customize their experience and the UI. Specifically, allowing users to hide the HTML and React buttons (essentially making this a controlled component via the defaultExample option) and allowing all buttons to be customized via slots vs a string in the config object (useful for showing icons or richer text for each button).

[break-stuff]

Let me think about the controlled example. The component is designed to dynamically display whatever examples are provided, so this may conflict with some of that logic.

Icons will be coming soon, but those will likely be added via the global config as well, so you don't need to configure each instance. do you think there will be a scenario where one instance will have different icons than the others?

[isabelacmor]

Sounds good - I think if there was a way to call updateConfig or another "hook" to change the framework dynamically, that'll be helpful.

Re: icons - I don't foresee needing different icons for the different frameworks. Those definitely feel like a top-level config.

One thing I noticed that I'll add here as well since it's related to types - it'd probably make sense to make at least one sandboxConfig required, but not require both. It seems like using strictly one sandbox option (CodePen or StackBlitz) rather than switching between both is a fairly common scenario. Not having to define unneeded properties would be helpful.

type CodeBubbleConfig = {
  /** Which sandbox environment your code will open in */
  sandbox?: 'codepen' | 'stackblitz';
  /** Configuration for the component rendered on the site */
  component?: ComponentConfig;
  /** Configurations for the sandboxes */
  sandboxConfig?: {
    /** CodePen sandbox configuration */
    codePen: FrameworkConfig<CodePen>;
    /** StackBlitz sandbox configuration */
    stackBlitz: FrameworkConfig<StackBlitz>;
  };
};

[break-stuff]

That's a really good call-out! It looks like there were a few other optional types I missed as well. They have been updated in 1.0.0-alpha.11.

[jehende]

@break-stuff do you have an approach for your comment below?

Let me think about the controlled example. The component is designed to dynamically display whatever examples are provided, so this may conflict with some of that logic.

Icons will be coming soon, but those will likely be added via the global config as well, so you don't need to configure each instance. do you think there will be a scenario where one instance will have different icons than the others?

[break-stuff]

I do. There is an option now, but I'm working on an API change that will make it easier.

[break-stuff]

Correction - I do not have something for the icons yet, but may have something soon.

[jehende]

@break-stuff please keep @isabelacmor aware of what you are thinking or strategies you take since Isabela's area is impacted by decisions taken here.

[break-stuff]

@isabelacmor configurable icons and labels have been added as of release alpha.29.