Closed MinaMatta98 closed 1 year ago
Now, hydration bugs mean that there are mismatches between client and server. I am using lazy_static and storing a Arc<parking_lot::RwLock<RwSignal
>>. It is possible that upon reload, they are partially dropped. However, what I cannot understand is why this only happens on release and not prod.
Does this mean you're storing signals in the lazy_static across requests? I would not expect this to ever work and it will cause pretty unpredictable issues.
In the absence of any way to reproduce this, my advice would be 1) Try the git main branch instead of 0.3.0, as there have been a number of hydration bugs fixed since then 2) Definitely do not store signals across requests (in a lazy_static) and try to use them)
Hmm,
It works...just in dev. The signals are reinitialized where they are not found. I am using the same method to handle my /Conversation and /Users route. It's working fine for the first, even at reload, making me think that it isn't the Global Var.
I initially wanted to introduce a reactive cache, that is why I was storing signals with alloc. I will initialize the variable using use_context instead, and see how that goes. I will, however, try to change to the git main branch prior to introducing the change. I recall the last time I tried this, I had a problem with leptos scope and leptos scope reactive. I'll give it another shot.
I will be working on solving this in the meantime.
Thank you.
I will, however, try to change to the git main branch prior to introducing the change. I recall the last time I tried this, I had a problem with leptos scope and leptos scope reactive. I'll give it another shot.
If this happens, it's because you didn't change the version of all the relevant Leptos dependencies, but only changed some of them.
It works...just in dev. The signals are reinitialized where they are not found. I am using the same method to handle my /Conversation and /Users route. It's working fine for the first, even at reload, making me think that it isn't the Global Var.
It may be totally unrelated to the hydration issue and still be bad news! Trust me; don't do this. The signal IDs are meaningless between different requests. They are the equivalent of indices into a Vec, such that storing a signal is storing "signal at index 3."
At best, they will seem to work okay because every request creates the signals in the same order. At medium, your application will randomly panic in unpredictable ways because of conditional logic while rendering requests made by different users. At worst, this has the potential to leak data between requests.
I initially wanted to introduce a reactive cache, that is why I was storing signals with alloc. I will initialize the variable using use_context instead, and see how that goes.
Yes, providing it via context instead of via a global variable is the way to do this.
Cheers :).
Really appreciate the advice.
Hello,
You may wish to close this. It is likely fixed within the next release, i.e 4.0.
It is peculiar that the bug presented itself only in dev, but since refactoring the codebase (sorry, the refactor was too large to track the change), it was likely attributed to an incorrect use of Suspense.
I'm not exactly sure why there was that slight discrepancy, though.
Describe the bug
cargo leptos watch --release
<--- Hydration errors with multiple items missing after hard reloadcargo leptos watch
<---- all elements render but warnings are present about signals dropped out of scope after hard reloadLeptos Dependencies
Please copy and paste the Leptos dependencies and features from your
Cargo.toml
.For example:
Expected behavior A clear and concise description of what you expected to happen.
Screenshots
Additional context It's difficult for me to reproduce this issue in a minimal version, but I suspect that the problem is related to the functionality of suspense.
Now, hydration bugs mean that there are mismatches between client and server. I am using lazy_static and storing a Arc<parking_lot::RwLock<RwSignal<Vec>>>. It is possible that upon reload, they are partially dropped. However, what I cannot understand is why this only happens on release and not prod.
Note that triggering a redirect via
<A/>
causes the items to successfully loadIf I find a workaround, as usual, I will post them here.
Thanks for your time.