zedux eslint rules

[joprice]

While using zedux over the course of several months, I've found that the main bugs I've hit are related to closing over stale state with injectPromise or exports. As it's probably not possible to represent in the TS type system, and is perhaps even a feature to read the "snapshotted" data, could zedux provide an opt-in eslint rule that detects usages where the state would be "static" relative to the execution of the atom, so that the user can annotate places where the intention is to close over the initial value versus the likely intended behavior of keeping the value reactive?

This can be pivotal to an app's logic, such as switching users or profiles (and have serious security implications), or some global setting that all other data is parameterized by. It's a common footgun in my experience to accidentally close over the value of an injectAtomValue, thinking it will be reactive, but missing it in a dependency array, or not using injectAtomGetters to get the up-to-update value.

[bowheart]

I'm not an eslint plugin expert, but I believe it's possible to at least check that functions passed to setExports or addExports don't reference any non-function, ref, or signal variables outside themselves. I'm not sure how hard it is to check those exports if they're defined outside the atom - e.g. returned from some injectOtherExports injector.

I just spent a few minutes prompting claude to do this. I think it's close, though its tests aren't passing. Not sure how much more effort it'll take.

@david-trumid what do you think? It sounds like something we could benefit from. I'm not sure how hard it is.

There is another approach we're considering that would indirectly address this: Proxy exports that allow the underlying references to change while keeping the references consumers access stable. I think that would be a more robust solution than an eslint plugin, though we'd have to investigate whether the tradeoffs are worth it.

[joprice]

That makes sense for exports. The other is non-declared dependencies, as is a common issue in vanilla react where an effect runs less frequently than intended. I’ve always felt that the deps interface is a bit lacking as it seems like the deps array should just be provided to the effect in react like it is for an injected selector in zedux. Of course there are cases like refs and others where you want to close over a stable reference without capturing but perhaps there could be another set of injectors that provide the deps to the closure. I never got the reason react didn’t do this in the original design of hooks. Is there perhaps a perf reason not to do this?

[bowheart]

There's definitely not a (good) perf reason. I suppose, since inline functions are expected, either API would require an eslint plugin to verify that all deps are declared, so they went with the one with less code.

useEffect((one, two) => ..., [one, two])
// vs
useEffect(() => ..., [one, two])

Zedux's selectors fix this, but only when declared outside the atom/component. Inline selectors are so convenient that we can't not support them. But they have the same problem.

The new dep-less injectMemo overload in v2 also has tradeoffs. You can't forget to pass a dep - reactive deps are tracked automatically as you use them. But everything has to be reactive - non-reactive values can't cause a rerun.

The best way to solve this problem is at compile-time, which is what lots of newer frameworks do out of the box, and is exactly what the new React Compiler is doing. We should probably start exploring a similar approach.