React

Wrap your application with <JazzProvider />, this is where you specify the sync & storage server to connect to (see Sync and storage).

import { JazzProvider } from "jazz-react";
import { MyAppAccount } from "./schema";

ReactDOM.createRoot(document.getElementById("root")!).render(
    <JazzProvider
        sync={{ peer: "wss://cloud.jazz.tools/?key=you@example.com" }}
        AccountSchema={MyAppAccount}
    >
        <App />
    </JazzProvider>
);

// Register the Account schema so `useAccount` returns our custom `MyAppAccount`
declare module "jazz-react" {
    interface Register {
        Account: MyAppAccount;
    }
}

Next.js

Client-side only

The easiest way to use Jazz with Next.JS is to only use it on the client side. You can ensure this by:

  • marking the Jazz provider file as "use client"
"use client"
import { JazzProvider } from "jazz-react";
import { MyAppAccount } from "./schema";

export function MyJazzProvider(props: { children: React.ReactNode }) {
    return (
        <JazzProvider
            sync={{ peer: "wss://cloud.jazz.tools/?key=you@example.com" }}
            AccountSchema={MyAppAccount}
        >
            {props.children}
        </JazzProvider>
    );
}
  • marking any file with components where you use Jazz hooks (such as useAccount or useCoState) as "use client"

SSR use (experimental)

Pure SSR use of Jazz is basically just using jazz-nodejs (see Node.JS / Server Workers) inside Server Components.

Instead of using hooks as you would on the client, you await promises returned by CoValue.load(...) inside your Server Components.

TODO: code example

This should work well for cases like rendering publicly-readable information, since the worker account will be able to load them.

In the future, it will be possible to use trusted auth methods (such as Clerk, Auth0, etc.) that let you act as the same Jazz user both on the client and on the server, letting you use SSR even for data private to that user.

SSR + client-side (experimental)

You can combine the two approaches by creating

  1. A pure "rendering" component that renders an already-loaded CoValue (in JSON-ified form)

TODO: code example

  1. A "hydrating" component (with "use client") that
  • expects a pre-loaded CoValue as a prop (in JSON-ified form)
  • uses one of the client-side Jazz hooks (such as useAccount or useCoState) to subscribe to that same CoValue
  • passing the client-side subscribed state to the "rendering" component, with the pre-loaded CoValue as a fallback until the client receives the first subscribed state

TODO: code example

  1. A "pre-loading" Server Component that
  • pre-loads the CoValue by awaiting it's load(...) method (as described above)
  • renders the "hydrating" component, passing the pre-loaded CoValue as a prop

TODO: code example