Avoiding component re-mount in StaticStatsigProvider Flags SDK (with Statsig as provider) example

[erakor]

Summary

Hi,

We are looking at using the Flags SDK with Statsig. The Statsig doc recommends to check out this example for a reference implementation on static pages.

Observed Behavior

For static pages, Statsig recommends using client bootstrapping. We've noticed that the current implementation of StaticStatsigProvider (link to example code) causes the entire application tree (passed as children) to unmount and then re-mount when the asynchronous data from the useBootstrap hook becomes available.

This behavior is caused by the conditional rendering logic that inserts the BootstrappedStatsigProvider into the component tree only after the data has loaded, which fundamentally changes the tree structure and triggers a full re-mount from React.

Here is the relevant code snippet from statsig-provider.tsx (link to example code)):

// L56-L72
  if (!data) {
    return (
      <StatsigAppBootstrapContext.Provider value={{ isLoading: true, error }}>
        {children}
      </StatsigAppBootstrapContext.Provider>
    )
  }

  return (
    <StatsigAppBootstrapContext.Provider value={{ isLoading: false, error }}>
      <BootstrappedStatsigProvider user={data.user} values={values}>
        {children}
      </BootstrappedStatsigProvider>
    </StatsigAppBootstrapContext.Provider>
  )

The reason for the re-mount seems to be the change in the React component tree structure:

1. During loading (!data): The tree is StatsigAppBootstrapContext.Provider -> children.
2. After loading: The tree becomes StatsigAppBootstrapContext.Provider -> BootstrappedStatsigProvider -> children.

This structural change causes React to discard the old tree and mount a new one, which can lead to undesirable side effects like loss of component state, re-running expensive useEffect hooks, and potential UI flashes.

Note: in the example, the client components also mount/remount.

Our Use Case and Challenge

Our primary use case for Client Bootstrapping is for client-side analytics and event logging (e.g., logging exposures, clicks, impressions, etc.). We have static pages

Given this, the current behavior presents a challenge:

• It either blocks the initial UI render until Statsig is initialized, or...
• It causes a jarring re-mount of the entire application, which disrupts the user experience and can lead to lost component state and unnecessary re-execution of effects.

Questions

• Could you provide some guidance on the recommended best practice for this scenario?
• How can we structure the provider setup to initialize Statsig without causing this mount/unmount cycle?

Thanks for your time and any guidance you can provide!

Additional information

No response

Example

No response

[icyJoseph]

Oh yeah that pattern is not good 🤔 As soon as a tag changes React discards the entire tree downstream.

Have you tried with statsig's own guide? https://docs.statsig.com/client/javascript-sdk/next-js/