---
title: "Migrating to @statsig/react-bindings"
description: "Learn how to migrate from the legacy statsig-react package to the new @statsig/react-bindings"
product: general
token_estimate: 1470
---
# Migrating to @statsig/react-bindings

> For AI agents: a documentation index is available at [/llms.txt](/llms.txt). Append `.md` to any page URL for markdown, or send `Accept: text/markdown`.

> **Warning:**
>
> ### Deprecated
>
> Migrate soon! Official support for statsig-react ended Jan 31, 2025.

> **Note:**
>
> Also refer to the [migration from js-client guide](https://docs.statsig.com/client/migration-guides/MigrationFromOldJsClient), which lists other impacts on statsig-react installations.

Breaking changes:

- The [initialization pattern](https://docs.statsig.com/client/migration-guides/MigrationFromOldReact#initialize) has changed, along with [waitForInitialization and initializeComponent](https://docs.statsig.com/client/migration-guides/MigrationFromOldReact#waitforinitialization-and-initializingcomponent).
- Bootstrapping has changed, now requiring a new hashing parameter: [Bootstrapping the StatsigClient](https://docs.statsig.com/client/migration-guides/MigrationFromOldReact#bootstrapping-the-statsigclient).

### Initialize

In the old `statsig-react` package, you had to give all values to the StatsigProvider, which internally set up the Statsig client instance. This approach caused issues in managing state between the Statsig client and the StatsigProvider, making it fragile and likely to break if you used the Statsig client directly.

The new approach runs everything through the Statsig client instance and passes it to the StatsigProvider.

#### statsig-react (Legacy)

```jsx
import { StatsigProvider } from "statsig-react";

function App() {
  return (
    <StatsigProvider
      sdkKey="<STATSIG_CLIENT_SDK_KEY>"
      user={{ userID: "a-user" }}
      waitForInitialization={true}
      // StatsigOptions (Not Required)
      options={{
        environment: { tier: "staging" },
      }}
    >
      <div className="App">{/* Rest of App ... */}</div>
    </StatsigProvider>
  );
}
```

#### New

```tsx
import { StatsigProvider } from '@statsig/react-bindings';
import { StatsigClient } from '@statsig/js-client';

// Create the client
const client = new StatsigClient(
  '<STATSIG_CLIENT_SDK_KEY>',
  { userID: 'a-user' },
  {
    environment: { tier: 'staging' },
  }
);

function App() {
  return (
    <StatsigProvider client={client} loadingComponent={<div>Loading...</div>}>
      <div className="App">{/* Rest of App ... */}</div>
    </StatsigProvider>
  );
}
```

> **Tip:**
>
> View the full example on [GitHub](https://github.com/statsig-io/js-client-monorepo/blob/main/samples/react/src/samples/react-precomp/sample-react-precomp-initialize.tsx)

### waitForInitialization and initializingComponent

In older versions of the `StatsigProvider`, you could set `waitForInitialization` to block children from rendering until the SDK fetched the latest values from Statsig. When you set `initializeComponent`, the SDK displayed that component while fetching values.

You could also set `waitForInitialization` to `false`, causing the StatsigProvider to render immediately before values were ready. Statsig didn't recommend this because values could change between checks, resulting in unexpected layout changes.

**Where did waitForInitialization go?**

The newer `StatsigProvider` removes this option to prevent developers from unintentionally allowing values to change mid-session. You can still replicate the `waitForInitialization=false` behavior, but Statsig doesn't recommend it.

Go to the [Initialization Strategies](https://docs.statsig.com/client/concepts/initialize) guide to learn how to replicate that behavior and for recommended synchronous initialization approaches.

### Bootstrapping the StatsigClient

When bootstrapping the Statsig Client in your React app from a Statsig Server SDK, you may need to update how the server SDK generates values. The `@statsig/js-client` SDK uses a `djb2` hash instead of `sha256` for hashing gate/experiment names. This doesn't change any bucketing logic, only the obfuscation method used for the payload.

By default, all server SDKs generate `sha256` hashes in the `getClientInitializeResponse` method. Set the hash algorithm parameter to `"djb2"` to bootstrap the new client SDK. This change also reduces the overall payload size, which benefits package size and speed.

For example, if you bootstrap from the Statsig Node SDK:

```js
statsig.getClientInitializeResponse(
  user,
  '[client-key]',
  {
    hash: 'djb2', // <- New Hashing Algorithm
  },
);
```

### Updating the user

#### statsig-react (Legacy)

```jsx
import { useContext, useState } from "react";
import { StatsigUser, StatsigProvider, StatsigContext } from "statsig-react";

function UpdateUserButton() {
  const { updateUser } = useContext(StatsigContext);

  return <button onClick={() => updateUser({ userID: "b-user" })}>Update</button>
}

function App() {
  const [user, setUser] = useState<StatsigUser>({ userID: "a-user" });

  return (
    <StatsigProvider
      sdkKey="<STATSIG_CLIENT_SDK_KEY>"
      user={user}
      setUser={setUser}
    >
      <UpdateUserButton />
    </StatsigProvider>
  );
}
```

#### New

```tsx
import { StatsigProvider, useClientAsyncInit } from '@statsig/react-bindings';
import { StatsigClient } from '@statsig/js-client';

const client = new StatsigClient('<STATSIG_CLIENT_SDK_KEY>', { userID: 'a-user' });

function UpdateUserButton() {
  const { client } = useClientAsyncInit(client);

  const handleUpdate = async () => {
    await client.updateUserAsync({ userID: 'b-user' });
  };

  return <button onClick={handleUpdate}>Update</button>;
}

function App() {
  return (
    <StatsigProvider client={client}>
      <UpdateUserButton />
    </StatsigProvider>
  );
}
```

> **Tip:**
>
> View the full example on [GitHub](https://github.com/statsig-io/js-client-monorepo/blob/main/samples/react/src/samples/react-precomp/sample-react-precomp-update-user.tsx)