fix: possible fix for hydration bug where it was killing text nodes o…

[i-Welch]

Work Done

• There is a bug when doing hydration where it seems to kill text nodes on inital hydration if they are wrapped in a signal at some point.
• Recreation here https://playground.solidjs.com/anonymous/ecb652e0-66e6-4289-b1f0-381ed1067fec (this playground does a few weird things to simulate hydration but I have a test project I can also send which exhibits the same behavior)
• Note: this reverts a performance optimization from a while ago and may not really be addressing the root issue which is that the hydration step if manipulating the DOM at all (or at least its manipulating the dom in such a way that this bug has occurred as a side effect)

To Test

• Create a simple hydration app based on the playground above and test this version of dom-expressions vs main and note that the bug is remediated. If you need help testing or something feel free to reach out

To Do

• I'm going to be working on a different fix that just stop hydration from manipulating the dom (or at least keeps it from nuking text nodes) but that may be a bit more complicated.

[i-Welch]

After doing some dissecting I can confirm that the issue is that the code running hydrate doesn't populate string and numbers into the elements it generates. From looking at the PR history this seems to be a performance optimization, but since the code also replaces the current Dom with the generated dom it causes certain strings and numbers to essentially just be disappeared until a signal is triggered to update that value in which case it returns (unless of course it's a static value in which case you're SOL)

[i-Welch]

I've tried to see if it's possible to just not insert the generated dom into root element but that seems to just break reactivity generally since the hydration code still attaches all reactivity to the generated nodes and not the existing nodes in the DOM

[i-Welch]

@ryansolid pinging this. This seems to be a pretty good fix at the cost of the performance improvement. If you don't think that's an acceptable outcome or I'm mistaken on what that code I removed actually does I'm open to spending more time here to try and find a different fix (which I think I have a pretty good idea what the fix will be but it's a bit more complicated) I'm good with that I'd just like a bit of movement in this.

[ryansolid]

Do you have an example closer to what you are after. Ideally we don't create DOM nodes during hydration. We're going in a direction where healing won't work long term so I'd rather find the cases where we are incorrectly creating DOM nodes rather than setting text nodes we should never need to set. I know there are some gaps here but I'd love to have more concrete example.

It is just that setting this back to correct the text still hides the more considerable underlying problem I think.

[ryansolid]

The examples here are creating new nodes rather than hydrating on the client (including in the test). Ie it isn't equivalent to what Solid's compiler generates. I don't see us merging this as the fix so I'm closing this. I need a better reproduction.