onMount randomly not called
What could be reasons why an onMount effect is not called at all in a completely random pattern?
It runs fine in like 19 of 20 times.
Other effects still run on the same request, while the onMount doesnt 🤯.
I am getting this in the latest solid 1.8.21.
74 Replies
What comes to mind is that either it's getting disposed, or it's getting suspended, or something weird is happening like throwing inside a cleanup handler or something
for the clenaup case you can check if a cleanup there is instead always called
for suspense I guess maybe you can check if a sibling memo is instead always called
I ran into some issue with 1.8.21 too (and 1.8.20)
I suspect it's because of the hydration changes, but I have no clue how everything connects
like so? 🤔
- some parent
- component with failing onMount
- different component with memo
1.8.20 was buggy with <Dynamic>, this got fixed in 1.8.21. But it seems like there is another bug? :thinkies:
https://discord.com/channels/722131463138705510/1273013394588565620
this one here
The issue I had was related to context
Actually it could've been a solid-primitives issue. I was using the
createBreakpoints
primitive and I just noticed it's doing changes depending on hydration. Although it was working in 1.8.19- some parent
- some component
- failing
onMount
- sibling memo
the last 2 are on the same level in theory, I don't know why they are rendered like thatsibling effects run 🥴
that's very weird
bug in Solid then I guess
I sadly dont have the time to debug this at the moment 🙈
e.g:
- component A onMount is skipped
- deep component B effect runs
It's better to try it with a sibling effect because the deeper effect could be under a root, under a separate owner, who knows
I'm experiencing this where a navbar component in the root of a router isn't executing onMount or createEffect statements like 50% of the time
which isn't making much sense...
but state changes coming from a store given by a provider are being reactive inside of the component?
@ryansolid could this be somehow related to the recent hydration changes? 🤔
Okay, just checked this, when the bug happens it skips all effects of said component, not only the onMount. And the component function itself is not skipped (e.g. console.logs in the component function are executed)
Just in case, this is the component where it is happening: https://codeberg.org/nitropage/nitropage/src/commit/bab5a12117781be480b7b4504d4416d64832db3c/packages/nitropage/src/components/admin/index.tsx#L36
worth checking now if a sibling memo is skipped too
I wonder if this is related to what I've been experiencing in https://discord.com/channels/722131463138705510/910635844119982080/1277514473611202581 and possibly https://discord.com/channels/722131463138705510/1273412699530858527 (EDIT: the second one seems like another issue)
Found a temporary workaround by reloading the page, if the effect did not run before document
onload
. Not happy about this but remarkable times sometimes ask for remarkable workarounds I guess 🙈. (https://codeberg.org/nitropage/nitropage/commit/63dd2ac23c25f4706985dc396b4d2a849294661e)
Okay this bug is worse than i thought... hovering or clicking on a link during hydration, also skips all effects 🤯waiit that's what's happening in the solid docs too!
if you hover over a link quickly after loading the page it 100% fails hydrating
We really need some @ryansolid magic here 😆
Not sure if this provides any good clue, but I was able to trigger effects not running with this:
https://github.com/solidjs/solid-start/issues/1614
haha I wasn't crazy!
I'm pretty sure some part of contexts in ssr broke with this too
It is possible this is related to the changes. Anyway to check against 1.8.19?
the docs are on 1.8.17 and it's happenig there too
Hmm...
and on router 0.13
Ok.. I imagine it is still related to hydration cancellation but maybe we've had this issue longer than I thought.
Hmm.. top level await not working is a Nitro issue their defaults are ancient and the expected override doesn't seem to work. However we did figure this out solve it months ago. I just don't remember where the setting was. You have to tell Nitro to use a higher target.
I'd be surprised if the connection of effects was anything but incidental
for me its happening with everything on latest (just in case 😅)
Again reproduction would help
I'd love to make a simple one but failed so far 🙈
fwiw I only started noticing the issues after 1.8.19. I was on 1.8.19 for a while and then after upgrading I started noticing the issues
Yeah the change was in 1.8.20, and then a small fix in 1.8.21. Hydration cancellation is more aggressive now. I wonder if effects for previously hydrated parts are getting stranded somehow.
This seems to be a pretty pervasive issue. Seeing this in 3 projects now
My guess is the problem is here..
GitHub
solid/packages/solid/src/reactive/signal.ts at main · solidjs/solid
A declarative, efficient, and flexible JavaScript library for building user interfaces. - solidjs/solid
I have an idea of how to change it but it's just a guess without having a reproduction to play with.
Solid docs next has the issue. @Jasi provided details above
The idea of this code is to hold user effects until all lazy components had hydrated. Sort of a hack but things were a bit too disruptive before. I think the problem is it doesn't account for the fact that context might be getting cleared earlier..
Video demonstrating the issue
Yeah its possible this has existed for a while and only got more prevalent after we got more aggressive here with the router.
Creating a full repro seems to be challenging so we have to give examples of where they exist in actual implementations. I have another (private) codebase I can share with you demonstrating another if you can't find what you need in the docs example
Ok I can finally reproduce it.. I was having a hard time moving the mouse fast enough on reload.
My internet is too fast, computer too powerful
I had the same issue. Throttling helped
Ok assuming I can get this going locally. I will debug tomorrow.
I'm having such a hard time reproducing this
I tried opening the stuff on stackblitz but it never loads..
gitpod loads but I can never seem to reproduce it
I wonder if it is harder to trigger in dev
I had to disable the search in all these environments because I don't have the profile so maybe its related to taht
I've noticed that a couple of the bugs aren't happening in dev but are in prod
Not sure what exactly the issue is but certain interactions no longer work like opening a Kobalte dropdown is broken or context values aren't being found
oh true, I quickly tried to reproduce it with the solid docs in dev mode and didn't manage to
@REEEEE maybe we should get Ryan access if you can constantly reproduce it in Inv?
I just got permission from Sam
Go for it
Will coordinate with Ryan in core
Yeah it could be related but its not the same issue
I will see if I can debug the prod docs site
ugh.. can't run it in replace because replay is some old fork of firefox that doesn't support Object.hasOwn
Which is used in one of the library deps
I'm going to just blind fix it. I know what the issue is. It might not fix all issues but I can fix the initial ones this way.
ok 1.8.22
@REEEEE give it a spin
Testing...
Seeing the same issue with the dropdowns
I can't figure out how to run the solid docs in prod mode locally lol. nitro just exists instantly after pnpm start
build without preset and then start?
I ran into that just now and had to remove the preset
oh, I have preset = node currently
yeah it needs to be
node-server
or not set
I tried node tooohh
thanks :zzz_flushedfroge:
weird I can't even reproduce the bug locally
with the old solid version
One thing I noticed with the dropdown issue is that it seems to rerender the trigger and children when I click it
:pepegeHmm:
I noticed the issues on our project are only in prod
I'm running prod
locally
*prod deployed
ohh
yeah weird, that seems to be the case here too
wait I might have a crazy theory
/issue located
@Jasi Can you try something really quick
for the docs
or I can I guess
if it takes 1 minute or less
should be in bed
nix in the microwave?
oh
nvm then, have a good night
:cozycat: good night!
I'm still testing it but
I seemed to have fixed the issue we were having on our project for the dropdowns by removing the children helper we were using to handle a function as children
Testing on the docs site to see if it's related
Did this fix the docs?
That was the one I was targetting
Cause I could actually reproduce it there
I'm testing now with latest solid
I can't reproduce it now with latest Solid (1.8.22) and removing the children helper
https://deploy-preview-860--solid-docs.netlify.app/
this might also be related to issues with
Switch/Match
@ryansolidwhy did you remove the helper?
but it seems fixed!
From what I can tell so far, this fixed both of my issues 🥳
- the effects (including onMount) ran reliably in all 30 tries (tab reloads) - link hover during hydration doesn't break the app anymore I gonna deploy it to prod next and make there a couple more runs 🙂 Edit: still no issues, after further use throughout the afternoon 🎉
- the effects (including onMount) ran reliably in all 30 tries (tab reloads) - link hover during hydration doesn't break the app anymore I gonna deploy it to prod next and make there a couple more runs 🙂 Edit: still no issues, after further use throughout the afternoon 🎉
It wasn't working by just updating solid
hm so the bug is still there with that specific case?
Yeah
I could be wrong but I downgraded solid on the project I'm working on to 1.8.18 and still had issues until I removed the children helper
yeah, the solid docs are on
1.8.17
currently
the bug was there before the hydration changes it seemsAwesome
I'm still getting stuff not running. What I can confirm though is that if I make a small change to a file in dev mode, the HMR causes things to finally run and everything gets into place as expected.
Its just the initial load not working, but after I've triggered HMR the app goes ahead and works fine.
If I set
ssr: false
, no problem, so for now I've got a client-only app and technically I could just go without Solid Start altogether in this case.