fix: ensure we check memos the first time a dependency uses them, even if the dependency always runs on its first run (closes #3181) #3182
Conversation
…n if the dependency always runs on its first run (closes #3181)
|
@metatoaster I'm trying to figure out the failing tests on |
|
Some of the tests I've added basically did document the existing behavior, not the ideal behavior, which I did comment in the test itself - in this test I was documenting the existing behavior where on departure from a component, the resource it needed was retrieved despite how it was on the verge of being disposed when hydrated, and while under CSR this wasn't an issue. Now both versions show the same expected behavior where this extra unnecessary fetch is no longer necessary, and that's a good thing. Moreover, this fix did correct other extra fetches which means those other tests need to pare down the counts, and again this is a very good thing. However, the concerning part is the base test case is picking up what appears to be the SSR counters from the CSR navigation, and its only for that particular test, which is weird, this is what I am more concerned about. I will get to the bottom of this, but in the mean time I am going to fix those tests. Edit: Looking at the test further it might appear that the browser for whatever reason isn't loading the wasm quick enough for that failure run, I put in a new pull request on top of this one (actually just one that included all the changes with this one), and the tests passed. |
- As leptos-rs#3182 fixed the issue where superfluous resource fetches happened when hydration happened inside a nested component, the expected values for the counters are down to where they actually are supposed to be.
* fix: ensure we check memos the first time a dependency uses them, even if the dependency always runs on its first run (closes #3181) * Correct expected counter values down due to #3182 - As #3182 fixed the issue where superfluous resource fetches happened when hydration happened inside a nested component, the expected values for the counters are down to where they actually are supposed to be. --------- Co-authored-by: Greg Johnston <[email protected]>
No description provided.