Best practice to instantiate and export instances of 3rd party libraries from atoms?

[marbemac]

I'm trying to instantiate instances of 3rd party libraries inside of atoms, and then expose the instance (using exports currently).

Is the below the best way to do this? I ran into issues with useRef, so I'm using useMemo and then exporting the instance.

One thing I ran into is that if I try to export the entire instance (vs specific functions), it seems to end up undefined when trying to use (see comments below).

This is with Zedux v2 rc.7.

import { createAuthClient } from 'better-auth/react';

export const authAtom = atom('auth', () => {
  const signal = injectSignal({
    jwt: null as string | null,
  });

  const client = injectMemo(
    () =>
      createAuthClient({
        fetchOptions: {
          onResponse(context) {
            const jwt = context.response.headers.get('set-auth-jwt');
            if (jwt) {
              signal.mutate({ jwt });
            }
          },
        },
      }),
    [],
  );

  return api().setExports({
    useSession: client.useSession,
    // client, // passing entire client here results in undefined in component (see below)
    jwt: () => signal.get().jwt,
  });
});

Then in the component:

const { useSession } = useAtomInstance(authAtom).exports;

// useSession is undefined for some reason in this version
// const { useSession } = useAtomInstance(authAtom).exports.client;

console.log('useSession', useSession);

[marbemac]

Going to have to setup something similar to instantiate an instance of the Zero client, which depends on the jwt from the auth atom. Will need to instantiate a new zero client and export a stable reference to that from something like a zeroAtom (and the client will be re-instantiated whenever the jwt changes). Similar to what they're doing in their zbugs app (using homegrown atom implementation) -> https://github.com/rocicorp/mono/blob/main/apps/zbugs/src/zero-setup.ts#L28-L50. Will share something here as soon as I have it working, to see if it's the right approach.

[bowheart]

@marbemac your approach with injectMemo is ok. I don't see a downside to it with better-auth's client specifically. But I have a couple notes for other cases:

When the third-party lib's object references can change, they're state. I wouldn't use memos, refs, or exports for that.

When you need the ability to tear down a third-party lib's objects, use injectEffect.

An example with both of these:

export const someThirdPartyClientAtom = atom('someThirdPartyClient', () => {
  const { jwt } = injectAtomValue(authAtom);
  const signal = injectSignal(null as ReturnType<typeof createSomeThirdPartyClient> | null);

  injectEffect(
    () => {
      const client = createSomeThirdPartyClient()

      signal.set(client) // the client is the state of this atom

      return () => client.destroy() // handle cleanup
    },
    [jwt], // rerun on jwt change
    { synchronous: true } // run the effect immediately
  );

  return signal;
});

(Could also do it like this to prevent the atom's type from being nullable:)

export const someThirdPartyClientAtom = atom('someThirdPartyClient', () => {
  const { jwt } = injectAtomValue(authAtom)

  // define the client immediately to prevent the type from being nullable:
  const signal = injectSignal(() => createSomeThirdPartyClient())
  const reasons = injectWhy()

  injectEffect(
    () => {
      const client = reasons.length
        ? createSomeThirdPartyClient()
        : signal.get()

      signal.set(client)

      return () => client.destroy() // handle cleanup
    },
    [jwt] // rerun on jwt change
    // `synchronous: true` no longer needed
  )

  return signal
})

It sounds like this is how I would set up the zeroAtom.

[marbemac]

Interesting - any upside to the second option, vs a cast in the first option? E.g. const signal = injectSignal(null as unknown as ReturnType<typeof createSomeThirdPartyClient>); in the first option (yes there is a little bit of unsafeness here re type, but other than that). Asking because the second option does feel more complex.

[bowheart]

Not really. With synchronous: true, you can guarantee that the state will be defined before anyone uses it. I do stuff like that fairly often, but I recognize it's technically imperfect.

Also worth noting, the complexity of the second example can be completely hidden in a custom injectSignalWithCleanup injector.

[bowheart]

As for why the entire client can't be exported, @marbemac, I believe you're running into a new, undocumented feature of Zedux v2. Exported functions are now batched and scoped by default. That means that the exact function reference you export isn't the same reference consumers call. This auto-wrapping only happens to functions.

I'm guessing that typeof client === 'function'. If so, Zedux will wrap it. Any static properties, like useSession, will no longer exist on the wrapped function. I'll look into this and see if there's a smart way to either prevent auto-wrapping or re-attach static properties in this case or, if not, if Zedux adjust the exported type to reflect that - if TS is saying that useSession is defined, it needs to be there.

In the meantime, there is a workaround: Pass { wrap: false } as the second parameter to api.setExports() to manually prevent auto-wrapping.

[marbemac]

Ah yeah typeof client === 'function' is indeed true. Will work around it thank you!