You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'll get straight to it, will dive into more details if you need.
boring example 1 - local state
classCounter{render(){return<Stateinitial={0}>{(val,set)=><divonClick={()=>set(val+1)}>
clicked {val} times
</div>}</State>;}}
all state changes with set() will not be reflected while replaying, BUT because it's 'local', you'd still 'start' and 'end' at the correct states.
boring example 2, spring animations
<Springto={10}>{val=><div>{val}</div>}</Spring>
this works fine! it might be dicey if you use onSpringUpdate to update something globally AND your timer goes out of sync. Didn't see it happen with simple examples.
this is tricky. lets say while recording, the request took 2 seconds, and on the 3rd second you did something to change global state based on this. then when replaying, if the request takes 5 seconds, then Putin conquers your apartment with babooshkas. (this is a similar problem to firing ajax requests in stores and trying to do record/replay)
So yeah, it's obvious that issues like this would come up, because 'replay flux' requires state to be managed centrally. That said, this is better than I expected, and I'm happy to recognize the limitations.
cheers!
The text was updated successfully, but these errors were encountered:
Record/replay is totally limited to the global state. Surely it won't play nice with the local state. Things like AJAX requests are supposed to be done in Action Creators in Redux, so record/replay won't cause them again.
Now, THAT said, there might be a hack here somewhere to be discovered. It strikes me that if these childfn's 'obtained' their state from the global state (atom/cursor/whatever), and then calling set() on these stores get registered into your action queue, then... something. I don't know yet.
I'll get straight to it, will dive into more details if you need.
boring example 1 - local state
all state changes with
set()
will not be reflected while replaying, BUT because it's 'local', you'd still 'start' and 'end' at the correct states.boring example 2, spring animations
this works fine! it might be dicey if you use
onSpringUpdate
to update something globally AND your timer goes out of sync. Didn't see it happen with simple examples.boring example 3
this is tricky. lets say while recording, the request took 2 seconds, and on the 3rd second you did something to change global state based on this. then when replaying, if the request takes 5 seconds, then Putin conquers your apartment with babooshkas. (this is a similar problem to firing ajax requests in stores and trying to do record/replay)
So yeah, it's obvious that issues like this would come up, because 'replay flux' requires state to be managed centrally. That said, this is better than I expected, and I'm happy to recognize the limitations.
cheers!
The text was updated successfully, but these errors were encountered: