Sub Modules and Contextual Atoms

[tpavlu]

Hey @dai-shi (and the community)

I was hoping to get a sanity check on an approach for injecting atoms into my sub modules.

General Problem Context

Here is a contrived example

• We have a userAtom which fetches from the API
• We have a derived atom to get their name in one component
• We have a derived atom to get their nickname in another component

This example is intentionally simple but in practice these derived atoms could be much more complex, joining data from multiple sources etc.

// src/main.ts
function App() {
  // renders a and b
}

// src/session.ts
export const userAtom = atom(async => fetch() /* fetch the user from API*/)

// src/component_a.ts
const userNameAtom = atom(get => get(userAtom).name)
function B() {
  const name = useAtomValue(userNameAtom)
  // use name
}

// src/component_b.ts
const userNickname = atom(get => get(userAtom).nickName)

function B() {
  const nickname = useAtomValue(userNickname)
  // use nickname
}

So if we want to move src/component_at.ts into its own package (pnpm in this example) with this target organization

// src/
  main.ts
  session.ts
  component_b.ts
// packages/
     a_module/
       src/
         component_a.ts

We would be unable to import the userAtom in component_a.ts without creating a dependency cycle. One approach to resolve this is to create another package for session.ts like this.

// src/
  main.ts
  component_b.ts
// packages/
     session_module/
       src/
         session.ts
     a_module/
       src/
         component_a.ts

Then our dependency graph can look like this

main => a => session
         => b => session

This all works fine and as expected, but has a few downsides

• We need to modularized session to modularize a
• It generally moves us away from dependency injection
• This is pretty different from how you would accomplish this with things like React.Context or Props since that allows for dependency injection

Possible Alternative

The goal here isn't to say if one is better than the other but to sanity check the alternative for potential issues or oversights.

Can we create a helper to build a createJotaiContext function that allows us to define some global jotai state containers but set their sources when component_a.ts mounts.

const UserContext: {
  user: Atom<User>
  Provider: React.ComponentType<{ user: Atom<User> }>
} = createJotaiContext(ctx => ({
  user: ctx.atom<User>()
}))

This can be derived from like this

const userName = atom(get => get(UserContext.user).name)

The boundary component needs to mount the Provider and supply these via props

function A(props: { user: Atom<User> }) {
  return (
    <UserContext.Provider user={props.user}>
       { // child components that consume the atom }
    </UserContext.Provider>
  )
}

How it works

Under the hood we just create an PrimitiveAtom<Atom<V>> for each key of the context you defined so for this example we made a PrimitiveAtom<Atom<User>>. The provider sets the backing Atom<User> from the props provided using useStore and .set

Concerns / Issues I see

• Multiple users of UserContext.Provider with different backing atoms could cause thrash / issues
• Access to any of the derived atoms from the context used outside of the react scope could cause issues since the provider atom will not be set

Benefits I see

• Allows to lean into dependency injection but still get syntactical niceties of Jotai / derived atoms
• Helps break cycles without needing to break out more modules proactively.

Overall not super sure how I feel about it but figured you or others might have good insight here and would love your thoughts

[dai-shi]

Not 100% sure, but it sounds close to Bunshi's goal.

[tpavlu]

Thanks for the direction!
I think at first glance this is actually solving the inverse problem, but I am going to take a deeper look and report back.

Thanks again!

[tpavlu]

Circling back just to share my findings here.
tl;dr Bunshi does help here and makes my code a good amount simpler which is great!

There are a few API things that keep it from working exactly how i like but that can be solved w/ some custom wrappers.

• You have to provide a default or else the value will be undefined
  • This is fine but means the type the ScopeProvider takes in will allow undefined. For my use-case I want to force the value to be provided as props and then remove the need for a default.
• You would need to create a molecule / scope per atom we want to inject or else it could cause downstream re-computation of all the derived atoms if a single prop changed at the injection layer.
  • This is solved by just having a layer to glue together the definitions of N key/value pairs but create independent scopes/molecules for them.

One limitation I ran into which had me pursue a different approach though was I couldn't seem to figure out how to subscribe to the molecule without using the react/vue layers. I wanted my result object from my helper to still be a Atom<T> that would internally read from the molecule. Without this the callers all would have to be aware of molecules which was undesirable.