custom results info banner

[itsgrimetime]

Features and Changes

Adds an environment variable toggle-able "CustomInfoBanner" that can be used to provide a custom banner on the experiment results view for self-hosted deployments.

This is achieved via a "DynamicComponentLoader" class that takes a componentName property and looks at env var flags (currently only one), and based on that conditionally loads a mapped component.

We use this currently to inform users of new features, documentation, or changes in how we are using GrowthBook internally. Ideally this would be something that's supported on the cloud-hosted instance as well, but I'm not sure really how that'd be able to be implemented (unless it just allowed completely static HTML). This solution is nice as it allows for dynamically loading a pre-compiled component, which can import and access experiment/org/user models and dynamically change the content based on that.

To enable this info banner the environment variable NEXT_PUBLIC_RESULTS_CUSTOM_INFO_BANNER needs to be set to true (otherwise the DynamicComponentLoader just returns null, resulting in no additional component being added to the results view).

Testing

I've attached screenshots showing an example of how we're using it, as well as what the results view looks like with NEXT_PUBLIC_RESULTS_CUSTOM_INFO_BANNER enabled (but no changes to CustomInfoBanner.tsx), as well as when the env var is unset/set to false.

Screenshots

[jdorn]

We've had thoughts of allowing custom Markdown to be injected throughout the app. I'm curious to hear more about use cases where having a full component is helpful. I'm wondering if markdown + a templating language is good enough to handle dynamic use cases. The nice thing about markdown + templating language is that we can persist that in Mongo and it doesn't require creating a custom build.

[itsgrimetime]

We've had thoughts of allowing custom Markdown to be injected throughout the app. I'm curious to hear more about use cases where having a full component is helpful. I'm wondering if markdown + a templating language is good enough to handle dynamic use cases. The nice thing about markdown + templating language is that we can persist that in Mongo and it doesn't require creating a custom build.

Yeah I think that would work pretty well, we only needed access to basic stuff like the user/experiment/org to generate the links back to internal services. I can take a shot at implementing that once I finish up some other work

[itsgrimetime]

closing this since the customized markdown templates are available now