is there a way to enforce access to an atom via exports?

[joprice]

I burnt some time while refactoring an atom that exposes an interface for loading, clearing and updating state, where I had one place in the code that was accessing the store directly, circumventing the exported callbacks. (I think I can use a typelevel approach to narrow the interface to enforce this and perhaps wrap the atom somehow in a proxy that returns a store that throws when the get/set state calls are made). But I wonder if a runtime check ability would be convenient for making an atom with "private" store, or if that's already possible using existing apis. I'd like to be able to go from an atom that is currently used in many places with directly state access to one that has a locked down interface, and feel confident that all the places the store was access, maybe even indirectly through abstracted helpers, are found.

Update: I just realized this might be what ions are for. Haven’t tried those out yet.

[bowheart]

Hey @joprice good question. There isn't currently any built-in way to prevent using the store directly.

perhaps wrap the atom somehow in a proxy that returns a store that throws when the get/set state calls are made

This wouldn't work since Zedux internally calls those methods on the store. I can't think of any way to do this currently besides crafting custom AtomInstance and AtomTemplate classes that overrides almost all the default behavior. That is possible, but pretty complex. It would take me several hours to put together at least, but I can see if I find time for it this week.

It would be about the same amount of work for me to add this as a full-fledged feature. I've been considering a concept of readonly atoms since I first explored Jotai. I believe your use case falls in that category (minus restricting "get" calls, I'll come back to that). I never implemented them because Zedux technically doesn't need them unlike Jotai, since Zedux is capable of reverse-mapping changes - derived atoms can propagate changes back to the atoms they derive from.

So the spec for this would be pretty simple: Readonly atoms simply don't have the .store property or the .dispatch, .setState, and .setStateDeep methods. You say you'd expect get (.getState) calls to error too. Is there a reason for that?

.exports would, of course, still exist and would become the only way to change the atom's state directly. To keep the atom truly "readonly", simply don't export anything that can change the store's state.

The spec will be different in v2, though even simpler. In v2, atoms won't expose a .signal property. You treat the atom instance itself as a signal. Reducers/.dispatch are also gone, so readonly atoms in v2 would only be missing .mutate and .set.

Creating a readonly atom could be done with either a readonly: true atom config option or a readonlyAtom factory. The former would be the most flexible (people could create their own readonlyAtom factories that simply call atom(key, stateFactory, { readonly: true })), so that's what I'm leaning towards.

I'm a fan actually. If this spec sounds like it fulfills your use case, I'll create issues for adding this to v1 and v2. I should say, if it can wait till v2, that's ideal, but not a problem if not.

[joprice]

After posting this, I ended up making a hacky cast function that zeroes out the Store type, so when I call my useAtomState wrapper and other helpers via an overload, I wind up with a pair of state and exports without the underlying function setter mixed in to the latter. That's enough for me for now to power the refactoring I mentioned, so no need to have my needs drive any plans.

Overall, having this built in would pair nicely with one of the best features of the library of providing an interface to each node in the state dag. It conveys the intention to the user in the strictest way and gives power to the library author.

I wonder if there would be a difference with my current approach of doing it purely with types though, since technically I could have a module private atom that exposes state, then export one that fixes the type to "readonly", avoiding an intermediary atom to act as a readonly proxy. Overall, is the overhead of an extra readonly atom like that negligible? (I'm assuming yes since I remember a benchmark showing atom creation compared to equivalent redux functionality being many orders of magnitude faster).

[bowheart]

I knew there was something I didn't reply to, sorry I'm just getting to this.

is the overhead of an extra readonly atom like that negligible?

Yes, very negligible. Zedux uses class instances internally for pretty much everything, making atoms and stores very lightweight. You can create millions of them without worries (well, as long as your graph isn't millions of nodes deep, or at least you aren't updating millions of them at once).

I want readonly atoms. I've wanted them for a while because of exactly this:

having this built in would pair nicely with one of the best features of the library of providing an interface to each node in the state dag

I will forego adding to v1 then. I have created #136 to at least discuss adding readonly atoms potentially to v2+.

[joprice]

Good to know there's little overhead. I'm considering using this for a streaming data processing backend pattern as well.

Looking forward to the readonly pattern. V2 sounds exciting with that and signals!