zeduxTypes.ignore in v2

[joprice]

I've just hit a case where I'm updating a refresh token on a user object when a token expires, and I don't want the app to go through a refresh cycle. I could split out the tokens from the user object into a ref and update that, since they are only accessed in callback scenarios, and don't need to be reactively updated. It seems that passing zeduxTypes.ignore to updates that only modify the tokens subfield of the user data would be appropriate here, but I remembered reading through this #118 and seeing a note on this facility no longer being necessary in the new version. Rather than digging myself into a pattern that's going to replaced, I wanted to ask in v2, is such a case possible with signals, where it's possible to "ignore" an update, as far as reactivity is concerned? Or should I just split tokens out into their own atom, where there's underlying storage accessing the user metadata, then there's two atoms - one state based and reactive for user metadata, and the other using a ref to hold onto tokens, allowing them to be updated without triggering any re-renders.

Aside

I also noticed in passing, when generating types for fsharp from the d.ts files using https://github.com/glutinum-org/cli, that the zeduxTypes object's fields are not readonly

zedux/packages/core/src/api/zeduxTypes.ts

Line 3 in 8b206e6

export const zeduxTypes = {

. The generated code on the fsharp side ends up having setters for the fields, but they are effectively constants and shouldn't be mutable.

[bowheart]

Good question @joprice I don't think I ever followed up on the TODO note I left in #115. It isn't that ignore is no longer necessary, it's more that it never was. You already found the replacement in refs.

V2 moves us into the signals world. Signals are "glitchless", meaning there's no state tearing. Every state update immediately propagates to all observers. An ignore command would break this model. While I've definitely used ignore in very controlled cases where I knew 100% that it was safe, it still always felt risky.

In short, it never was a good idea. Reactive values should be reactive, always. Non-reactive values are what refs are for.

But before we get too caught up in the refs approach, there's a better pattern I'd recommend first: Keep all values reactive, but split them up. Zedux atoms can choose whether to register static or dynamic dependencies.

const userTokensAtom = atom('userTokens', () => ({ refreshToken: null, token: null }))

const userDataAtom = ion('userData', ({ getInstance }) => {
  // use `getInstance` instead of `get` to register a static dependency:
  const tokens = getInstance(userTokensAtom).getState()
})

This way, you're still free to hook into token updates reactively if needed. And you can also choose to not, so you can prevent the app going through a full refresh cycle on token change.

Anyway, that's a suggestion. Back to refs: You could use a separate atom to store the ref. It doesn't have to be separate though; I often attach refs to atoms with other reactive values.

const partiallyReactiveAtom = atom('partiallyReactive', () => {
  const signal = injectSignal({ reactiveValue: 'here' })
  const ref = injectRef({ nonReactiveValue: 'here' })

  return api(signal).setExports({ ref })
})

[joprice]

I like both of these approaches. I just tried out the ignore setup and got it working, and now token refresh don't cause abort errors, causing a logout. So my code is at least structured to isolate the two types of updates. I can now refactor the underlying atoms into one of these approaches.