Closed kenneth-gray closed 1 year ago
Whoops - haven't been watching the videos this time round and I can see how it ends up in extra credit 7 before onReset
is used. I can also see how in the non error scenario with the key changing every time it is re-rendering everything 😅
I think it might still be useful to move the solution into extra credit 8 after resetKeys
is added in and clarify (again) why it's better than using key
. I appreciate that would end up needing to re-record both extra credit 7 and 8!
Happy to close 😄
For this extra credit, using
resetKeys={[pokemonName]}
is effectively the same as usingkey={pokemonName}
, because it ends up mounting the<PokemonInfo />
component from scratch. This means the UI still flashes up theidle
state.One way to fix the problem of the flashing
idle
state is to check thepokemonName
when setting the initialstatus
property on the state object. I can see this has been done in the final exercise files for both extra credit 7 and extra credit 8.Suggestions:
status: pokemonName ? 'pending' : 'idle'
for extra credit 7, because it doesn't naturally fit with the flow of what is being asked for. (unless I've misread something)resetKeys=[pokemonName]
acts similarly tokey={pokemonName}
and prompt them to think how else the<PokemonInfo />
can be changed so that thestatus
doesn't always start asidle
.Happy to raise a PR if you agree.