Guidance of how to use useEffect to react on state changes

[saendu]

I was debugging how I can react on state updates with useEffect. But the results between working with the state object directly as a dependency or using the snapshot, was quite confusing. Sometimes both work sometimes working directly with the state object did not trigger the useEffect callback function.

Can someone give me guidance which one of these options I should use:

// with state object directly
useEffect(() => {
    console.log('do magic with', state.watchObj)
}, [state.watchObj])

// with snapshot
useEffect(() => {
    console.log('do magic with', snapShot.watchObj)
}, [snapShot.watchObj])

// with subscribe
useEffect(() => {
    const callback = () => {
      console.log('do magic with', state.watchObj)
    }

    const unsubscribe = subscribe(state.watchObj, callback)
    callback()

    return () => {
      unsubscribe()
    }

}, [])

Is really the last option the way to go, or can I use one of the slimmer versions above?

[dai-shi]

Yeah, you are hitting the difficult part of proxy state.
The last option is actually preferable and less error-prone.

If you want to use useEffect deps, the recommendation is to extract primitive values from snapshot in render, and pass them:

  const snap = useSnapshot(state)
  const { num, string, bool } = snap.watchObj
  useEffect(() => {
    ...
  }, [num, string, bool])

This also applies to useMemo and useCallback deps, and also memo.
We should add notes in https://github.com/pmndrs/valtio/wiki/Some-gotchas.

[saendu]

Thank you for your prompt answer. If no technical implication I would like to use the option to pass deps to useEffect rather than the bloated option with subscribe(). Is my assumption correct that that I could also just pass the primitives directly to the dept array like so:

  const snap = useSnapshot(state)
  //const { num, string, bool } = snap.watchObj
  useEffect(() => {
    // change state here 
    state.otherObject.num = 0
  }, [snap.watchObj.num, snap.watchObj.string, snap.watchObj.bool])

As a mnemonic: Should I always use snap when reading values, and only use state directly when writing to it? So useEffect dependency array is reading, hence snap and when changing state inside of the useEffect callback, I should use state directly?

[dai-shi]

If no technical implication

Well, state is mutable in valtio, but React expect immutable values for deps. So, there's technical mismatch.

I could also just pass the primitives directly to the dept array like so

It works. Although, it's not ideal. You want to use the same primitive values in effect, that you specify in deps.
Hypothetically, state and snap can have different values. (there's timing issue)

Should I always use snap when reading values

You should use snap in the render function to get reactivity. all other cases should use state.

What is your use case of useEffect? If you just want to change a state value based on other state values, we usually wouldn't use useEffect.

[saendu]

As you assumed correctly I was trying to change a state value based on certain other state changes. Therefore I was using useEffect with dependencies, to catch those changes and fire the callback. But maybe this is kind of an anti-pattern.

For example, loading favourites from a user profile and loading data based on those favourites:

useEffect(() => {
        (async () => {
            const data = await load(snap.commonData.ingredients)
            state.results = data
          })()
}, [snap.profile.favourites])

This will be executed in a component (like a global search) and later used in different components, rendering those results across the application.

[dai-shi]

change a state value based on certain other state changes.

If this doesn't require other values like props in a component, valtio practice is to do it outside react.

subscribe(state.favourites, async () => {
  state.results = await load(state.commonData.ingredients)
})

If something depends on data in component tree, then we need to use hooks.

[saendu]

You should use snap in the render function to get reactivity. all other cases should use state.

I am using functional components, where everything defined in the function's body is the render function.

Hypothetically, state and snap can have different values. (there's timing issue)

This makes my brain hurt a little. So what is your guidance in a case like that:

   useEffect(() => {
        // state.results = [...] // has many values in array

        let local = false
        if(conditionThatIsTrueOnlyOnce === true) {
            state.results = []
            local = true
        }
        if(snap.results.length === 0 && local === true){
            console.log('will this trigger or not?')
        }
    } , [deps])

Is this a timing issue, since the update of state and reading of the snapshot happens too quickly? Am I missing something here?

[webcodion]

Hi there!

Would it be possible to adapt eslint in a way so it doesn't complain about this pattern?

const {num} = snap.obj;
const handleClick = useCallback(e => {
    if (num !== 1) {  // eslint-disable-line valtio/state-snapshot-rule
        ...
    }
}, [num]);

And I'm curious, what would you use?

What is your use case of useEffect? If you just want to change a state value based on other state values, we usually wouldn't use useEffect.

[dai-shi]

We have some discussions lately in pmndrs/eslint-plugin-valtio#16.
However, it turns out it's not possible to detect with lint. In your case, the linter can't know if num is just a number or it can be an object.

[dai-shi]

And I'm curious, what would you use?

just derive a value in a hook/component, or use derive.

[webcodion]

Is it correct that valtio will create a copy of objects which are put into a store's variable? Or is that how Proxies work in general? I noticed that it doesn't reference the original object anymore. However, when I use ref(), it works as expected.

[dai-shi]

Yes. It's a specific behavior in valtio, not proxies in general.
The idea is "creating" a proxy object from an initial object, instead of "wrapping" an exiting object with a proxy object. It's probably technically possible to do the latter (wrapping), but I chose the former (creating) to be less error-prone.