detecting duplicate atom registration

[joprice]

I just hit a bug where I duplicated an atom and renamed it's binding const a -> const b, but didn't change it's name, and was surprised to find that it didn't fail at runtime. For instance, defining these atoms with duplicated key:

const a = atom("a", ....)
const b = atom("a", ....)

I have a feeling this is a feature, as I saw in the docs that you can override atoms, e.g. for testing purposes. I think I even made use of it at one point already, but I'm curious if there could be a strict mode where duplicate atom registration fails, since I would imagine in most cases, atom names are meant to be distinct.

I'm also curious about the expected behavior in the meantime, since I think what I'm seeing is the first one registered taking precedence. If that's the case, then it's not overriding, but ignoring duplicate registrations, so seems easier to introduce a strict mode that rejects the second call in that case.

[bowheart]

Hey @joprice. It is indeed a feature. Zedux inherited it, along with its problems, from Recoil.

Lots of people complained about that part of Recoil and it's probably the main reason Jotai became popular. It's something we definitely don't want to change because it facilitates cross-realm state sharing. Predictable string keys/ids are the reason Zedux is more capable than Jotai when multiple windows, SSR, or web workers are involved. I also turned it into a Dependency Injection feature.

Learning from React Query

Other tools like Storybook and React Query have the same problem. They're just as vulnerable to copy-paste. But there is something we can learn from React Query: It's less vulnerable to other accidental duplication since their model naturally namespaces query keys based on API endpoints.

I think I'm going to recommend a similar practice in the Zedux best practices guide. Namespace atom keys by feature - e.g. dashboard/usersTable/filters.

But again, this won't help with copy-paste. Here are some things that will:

The instanceReused mod

In v1, you can detect when an atom instance is reused even though a different template was passed using the instanceReused mod:

const duplicateDetectorPlugin = new ZeduxPlugin({
  initialMods: ['instanceReused'],

  registerEcosystem: ecosystem => {
    const subscription = ecosystem.modBus.subscribe({
      effects: ({ action }) => {
        if (action.type === ZeduxPlugin.actions.instanceReused.type) {
          const { payload } = action

          if (payload.instance.template !== payload.template) {
            console.warn('Reused instance from a different template', instance, template)
          }
        }
      },
    })

    return () => {
      subscription.unsubscribe()
    }
  },
})

myEcosystem.registerPlugin(duplicateDetectorPlugin)

Though this doesn't play well with HMR/React Fast Refresh since those create new atom template object references. Because of this, it's already gone in v2.

Zedux v2

In v2, I want to completely rework this. The roadmap (#118) has this item:

Remove the string key requirement of atom. Keys will be auto-generated if not provided (but it's strongly recommended to pass one or use a build tool plugin to generate them for you).

In particular, it will be strongly recommended to let a build tool plugin generate them. That will ensure all atom keys are unique and have the same name as the variable they're assigned to (probably minus the Atom suffix or any other naming conventions that arise). It can also warn you if it encounters two atoms that would have had duplicate keys.

With a build tool, declaring a string key should never be necessary. Even when you do want to override an atom, use the atom template's .override method instead of manually duplicating the key string.

I have experience building Vite plugins in particular and will make one.

Side Note: Centralized Keys

Another thing we can learn from React Query: I've heard of people centralizing their query keys in a single file so JS will error if you export duplicates. While it would help with this problem, the little amount of time this could save isn't worth the overhead. It isn't considered best practice in React Query, so I'm not recommending it either.

Last Thing

Some personal experience: This is something you just figure out over time. I remember debugging problems caused by accidental duplication probably three times in my first few months working with Recoil and Zedux. I might have duplicated keys once or twice since, but immediately find the problem. Overall, I'd say this problem has cost me maybe half as much time in my life as typing this reply.

Even leaving the problem completely alone, in my experience, it costs less time than trying to use non-atomic state managers.

This problem is the nature of the beast when working with atomic ("bottom-up") state models instead of Redux's top-down model. I don't want to pretend the problem doesn't exist like Jotai did at first as that leads to long-term problems with codebase grepability and cache discoverability.

The build tool is the perfect means to circumvent it. In v2, if people prefer, they can omit the keys entirely. Though I'd argue that will cost more time in the long run.

[joprice]

Thank you for all the context. It makes sense why it behaves this way.

The build tool suggestion sounds like the right way to go, and I am using vite for a few apps, but I also have a react native app. For that ecosystem, I guess a babel transform would be the way to go, but I'm not that familiar with babel.

I think for now, I'll just add an "atom factory" function that maintains a set and throws if a dupe is found. Since I'm currently not doing anything much more complex than defining unique, top-level definitions, it should be enough to stop me from shooting myself in the foot at least.

[joprice]

It just occurred to me that the idea of using a factory that stores the dupes won't work for fast refresh, and maybe other cases where the atom definition is re-run, where it's not the first definition. Doing this at compile time or with some build tooling metadata that's aware of source location seems like the only way.