How to reset state/proxy on component unmount?

[epsilon42]

Loving the simplicity of valtio, however I am trying to figure out how to achieve the following behaviour:
Normally with React I can rely on any state for a component (or provider component) being cleared when the component is unmounted. How can I mimic this behaviour with valtio?

Please refer to CodeSandbox here: https://codesandbox.io/s/modern-rgb-x9pef

1. Clicking 'Toggle View' to show counters
2. Increment the 'Valtio test' counter
3. Click 'Toggle View' to hide counters
4. Click 'Toggle View' to show counters
5. Observe how the 'Counter' count has persisted after hiding and showing the component

Desired behaviour: counter resets when hiding then showing component (like the 'React useState test' counter).
Use case: user is navigating from one page of my React app to another, and when returning to the page I want the inputs/state to reset.

I'm guessing this is probably something very basic or I'm using the wrong pattern. Any help would be appreciated!

[dai-shi]

In this case, I would suggest to reset proxy state explicitly.
https://codesandbox.io/s/currying-cherry-yh5ip

How can I mimic this behaviour with valtio?

Alternatively, you could store the proxy state in useRef to work with react component lifecycle.

export const ValtioLocalStateTest = () => {
  const state = useRef(proxy({ count: 0, userName: "Default userName" })).current
  const snap = useSnapshot(state)

  return (
    <div>
      <h3>Valtio local state test</h3>
      <div>Counter: {snap.count}</div>
      <div>
        <button onClick={() => ++state.count}>Counter +1</button>
      </div>
      <div>Username: {snap.userName}</div>
      <div>
        <input value={snap.userName} onChange={(e) => { state.userName = e.target.value }} />
      </div>
    </div>
  )
}

But this doesn't make much sense. useImmer would be a better fit for local state.

[epsilon42]

Thanks for the quick response @dai-shi. Will look into useImmer but would prefer the valtio pattern if I can make it fit!

I think I can use something similar to your CodeSandbox to trigger reset on component unmount instead:

import { useEffect } from "react";
import { Dashboard } from "./Dashboard";
import { Controls } from "./Controls";
import { reset } from "./state";

export const ValtioStateTest = () => {
  useEffect(() => {
    return () => {
      reset();
    };
  }, []);

  return (
    <div style={{ background: "#ddd" }}>
      <h3>Valtio test</h3>
      <Dashboard />
      <Controls />
    </div>
  );
};

But this has made me think about the following scenarios:

• I can see myself accidentally doing something like: state.someLargeObjectNotInInitialState = { ... } from another component. The reset() wouldn't remove this property. Would be great if I could do state = {...initialState}, but unable to do that. Should I maybe iterate through state and delete each key in the reset()?
• If I have a large web-app with 100's of pages that each required their own state (i.e. created a similar state.js for each page), won't this mean that all these states are kept in memory all the time?

[dai-shi]

Thanks for the quick response @dai-shi. Will look into useImmer but would prefer the valtio pattern if I can make it fit!

You can use the useRef pattern, if you prefer. It works.

I think I can use something similar to your CodeSandbox to trigger reset on component unmount instead:

Yeah, this works too.

Just note, in the future version of react, useEffect will be dual invoked in DEV.
It's generally recommended that effect&cleanup is paired.

But this has made me think about the following scenarios:

• I can see myself accidentally doing something like: state.someLargeObjectNotInInitialState = { ... } from another component. The reset() wouldn't remove this property. Would be great if I could do state = {...initialState}, but unable to do that. Should I maybe iterate through state and delete each key in the reset()?

Yes, iterating sounds good.
Alternatively, you can have the state nested.

const initial = { a: 1, b: 2 }
const p = proxy({ obj: initial })
const reset = () => {
  p.obj = initial
}

• If I have a large web-app with 100's of pages that each required their own state (i.e. created a similar state.js for each page), won't this mean that all these states are kept in memory all the time?

True. It's how global state works.
If you only need the state with in the page, you want to create the state in the page and put it in useRef.
Or, attach it on page mount and remove it on page unmount.

[virsir]

I read the wiki

const reset = () => {
  const resetObj = _.cloneDeep(initialObj)
  Object.keys(resetObj).forEach((key) => {
    state[key] = resetObj[key]
  })
}

1. why need cloneDeep, is that really necessary
2. It seems too complicated to me
3. I am not sure, is below ok? @dai-shi

const initial = { a: 1, b: 2, c: {aa : 1} }
const p = proxy( initial )
const reset = () => {
  Object.assign(p, initial)
}

[dai-shi]

You don't need JSON stringfy hack, the valtio lib will copy the object anyway.

const reset = () => {
  p.state = initial
}

[niraj-khatiwada]

You don't need JSON stringfy hack, the valtio lib will copy the object anyway.

const reset = () => {
  p.state = initial
}

Interesting. But I can't seem to make it work through. Here is an example. I have this setup for the proxy store. It's a form but I want to reset it whenever the component is unmounted. If I do the JSON method, it works as expected. But if I just the normal, it resets the email, image, etc but it does not reset the nested states inside invalidMessage.

Works:

Does not work:

[dai-shi]

My bad. It skips when assigning the same object.
Try this instead:

  store.state = { ...initial }

[niraj-khatiwada]

My bad. It skips when assigning the same object. Try this instead:

  store.state = { ...initial }

Unfortunately, this does not work as well. My guess is since the spread operator only does shallow copy. JSON.parse(JSON.strigify(initial)) is the only way.

[dai-shi]

Oh, actually, #634 changed it (fixed in a sense).
Yeah, deep copy would be necessary.

We should update the docs. Would you be willing to work on it?

I prefer lodash cloneDeep to JSON.parse, even though it can be fast in some cases.

[user753]

Hi. I have this scenario

const initialSubstate = {foo: 123}
const initialState = {substate: initialSubstate, bar: 234}
const store = proxy(initialState)
store.substate.foo = 345
store.substate = initialSubstate

It feels weird that it doesn't work like that and valtio compares them by reference even the substate was modified and some cloning need to be used.

store.substate = deepClone(initialSubstate)

Why valtio cannot figure out that substate had been modified and need to be re initialized even if it the same object ref?
I guess the initial ref for initialSubstate object is stored somewhere to compare it with new one. I think if the object was changed the initial ref could be set to undefined or something like that.
Is it possible to have some option to disable this checking?

[dai-shi]

It's by design, and I'm sure it helps (optimizes) in some cases.
Having that said, I'm getting similar feedback, and may consider changing the behavior in the future version (v2).

Meanwhile (v1), please copy the initial object before calling proxy.

import { proxy as proxyOrig } from 'valtio';

export const proxy = (initialObject) => proxy(cloneDeep(initialObject));

Hope it works.

[user753]

Thanks, but unfortunately it doesn't work for the second reset

const initialSubstate = {foo: 123}
const initialState = {substate: initialSubstate, bar: 234}
const store = proxy(JSON.parse(JSON.stringify(initialState)))
store.substate.foo = 345
store.substate = initialSubstate
console.log(store.substate) // 123
store.substate.foo = 567
store.substate = initialSubstate
console.log(store.substate) // 567

[dai-shi]

oh, right. can't be helped. your original workaround should only do. I'd admit it was a bad design choice in your use case.