forked from OpenNeo/impress
Emi Matchu
258b360ff2
A bit of a hack, because the thing triggering it was also a bit of a hack? I feel like there's something we gotta do with refactoring how our multiple concepts of state are managed… but in any case! This seems to keep basic outfit-loading working, while no longer getting us trapped in autosave loops! Here's how I reproduced the bug: 1. Open a saved outfit. 2. Set the browser devtools to apply a latency of 5sec to all requests. 3. Add an item to the outfit, and wait for the autosave to start. 4. While it still says "Saving", remove the item again. 5. Watch how, when the first autosave request comes in, the item is re-applied to the outfit, then autosave gets stuck looping forever. The issue was that, when an outfit finishes saving, the change in outfit data was triggering this effect in `useOutfitState` that was *meant* to *initialize* local state from the saved outfit, not to keep them in sync all the time. (In general, when saved outfit data comes back from the server, we don't want to use it to "fix" local outfit state in the case of discrepancies, because the most common source of discrepancy will be the user having made further changes!) But anyway, one thing I didn't realize is that we *were* depending on this hacky hook to do more than I thought: it was responsible for syncing `id` and `appearanceId` to the local state after saving the outfit. So, I replaced the `rename` action dispatch here with a new action that explicitly sets all fields the server is responsible for! |
||
|---|---|---|
| .. | ||
| components | ||
| images | ||
| ItemPage | ||
| loaders | ||
| WardrobePage | ||
| apolloClient.js | ||
| AppProvider.js | ||
| impress-2020-config.js | ||
| index.js | ||
| ItemPageOutfitPreview.js | ||
| util.js | ||