ryansolid Comments - Answer Overflow

Topics

ryansolid

•Created by MaxLarionov0916 on 6/28/2024 in #support

Bug? with ssr, lazy loading, and css.

Yeah any issue that affects prod needs to be elevated. In digging into other CSS issues I'm starting to get an idea of the gaps of the solution here. We're probably going to need to supplant Vinxi's current solution and find a fix until we can back port. I apologize CSS has been a blindspot becaus it isn't a place that typically gets exhausted in demos, so I wasn't seeing many of the issues before and it only takes one break in the chain. Like the FOUC people are seeing in DEV was introduced by a side effect of a different fix in Vinxi and it isn't supposed to be there either. So CSS is playing a bit of a whackamole thing on bugs right now.

14 replies

•Created by willkelly on 5/17/2024 in #support

Potential upstream problem in solid for users of Astro + solid + cloudflare?

That is an odd one. it generally means server code is running at a point where there is no server context which shouldn't be possible. Like something outside of a render or not sure.

22 replies

•Created by willkelly on 5/17/2024 in #support

Potential upstream problem in solid for users of Astro + solid + cloudflare?

I would expect the browser mapping either to happen first or not happen when export conditions are involved. But to have both run and the browser mapping to run afterwards makes zero sense. Like we need the browser mapping or old tools like Jest which didn't support export conditions. That was the only way to get the browser version in node. But to have it also apply on top of things that get mapped to the server via export conditions is just nonsensical.

22 replies

•Created by willkelly on 5/17/2024 in #support

Potential upstream problem in solid for users of Astro + solid + cloudflare?

My understanding is that the browser version of Solid is getting pulled in on the server because while the webworker export condition is properly handled for some reason unknown to me they then run it through the toplevel browser mapping. Which remaps it back to the browser build. It feels like a bug in all the modern tool stack but no one seems interested in fixing it.

22 replies

•Created by willkelly on 5/17/2024 in #support

Potential upstream problem in solid for users of Astro + solid + cloudflare?

The first error suggests there is a place where sharedConfig.context isn't defined. I did see something in Astro/Solid Adapter that surprised me where it was using the <NoHydrate> wrapper. I'm gathering to reduce output size but I think there are somebugs with it and Suspense. We haven't used it ourselves for that and to be fair.. Astro didn't originally support async Solid rendering on the server so Suspense wasn't an issue. So I think that looks like just a Solid bug/adapter bug that should be addressable. The second issue does also seem like a top level fragment issue. I've been chasing these down for a while. It is probably something odd in the Solid/Astro adapter code that we don't hit typically in apps. My understanding of the issues were things that were specifically related to cloudflare. If those are, I'm a bit surprised, but otherwise those just seem like specific code bugs and not bundling issues.

22 replies

•Created by willkelly on 5/17/2024 in #support

Potential upstream problem in solid for users of Astro + solid + cloudflare?

Hey just got back from vacation. It's tricky as I said because in a sense we rely on the behavior being the way it is for Jest to work. And when we suggested that the way many tools were handling things was odd and incorrect people tended to agree but pointed at another tool that had this behavior and basically wouldn't change it. I'm curious @alex (he/him) if there is something to be done at the vite-plugin level but my understanding was this had to do with browser field resolution of the solid-js package itself.

22 replies

•Created by willkelly on 5/17/2024 in #support

Potential upstream problem in solid for users of Astro + solid + cloudflare?

I think the hardest part of this is that we can't make such a move on a patch release. We'd have to do a minor most likely otherwise risking back compat.

22 replies

•Created by willkelly on 5/17/2024 in #support

Potential upstream problem in solid for users of Astro + solid + cloudflare?

I think the shortest path is see if newer Jest works without the browser field and see if we can remove it.

22 replies

•Created by willkelly on 5/17/2024 in #support

Potential upstream problem in solid for users of Astro + solid + cloudflare?

I'm not sure.. there are a bunch of open issues from when this conversation started. It hadn't impacted us much until now that I guess they are trying to remove compatibility.

22 replies

•Created by willkelly on 5/17/2024 in #support

Potential upstream problem in solid for users of Astro + solid + cloudflare?

It's annoying because while we could fix it.. I'm almost positive it will break Jest.. Most people involved in the conversation agreed the behavior was unexpected but no one was interested in fixing it.

22 replies

•Created by willkelly on 5/17/2024 in #support

Potential upstream problem in solid for users of Astro + solid + cloudflare?

I see.. this is actually the most relevant thread: https://github.com/solidjs/solid-start/issues/263

22 replies

•Created by edygar on 5/11/2024 in #support

Hydration mismatch

I mean client-wise I can see createMemo only have it call once, but the question I guess is there still a mismatch there.

25 replies

•Created by edygar on 5/11/2024 in #support

Hydration mismatch

So every time props.test is called it would create the Div again. That being said.. createMemo I'd expect to be fine here.

25 replies

•Created by edygar on 5/11/2024 in #support

Hydration mismatch

Because it roughly compiles to:

ReproduceSteps({
  get test() {
    return {
      propertyBesidesElement: "test",
      element: createElement("div")
    }
  }
})

ReproduceSteps({
  get test() {
    return {
      propertyBesidesElement: "test",
      element: createElement("div")
    }
  }
})

25 replies

•Created by edygar on 5/11/2024 in #support

Hydration mismatch

The problem here is that even without SSR you are rendering the elements multiple times.

25 replies

•Created by Some Call Me Tim on 4/11/2024 in #support

Solid Start Route for simple redirect

It does not need to be under /api. You can set any path you want.. it will be the same name as the file.

4 replies

•Created by zimo on 4/9/2024 in #support

Failed to execute 'replaceChild' on 'Node': The node to be replaced is not a child of this node.

Yeah Solid doesn't observe the DOM and just keeps references. It assumes it is in the state it is left in from a declarative standpoint. There is some flexibility in terms of being able to augment on top of that but if it falls back to Solid doing updates from declarative templates it won't have known if things have moved when it expects them to be there.

7 replies

•Created by zimo on 4/9/2024 in #support

Failed to execute 'replaceChild' on 'Node': The node to be replaced is not a child of this node.

Hmm.. that's an odd error, it suggests that DOM nodes are getting moved in an unexpected way. That's a rendering error. The store is probably related, but this error happens when there are references to DOM nodes.. things getting inserted outside of the framework usually..

7 replies

•Created by zimo on 4/9/2024 in #support

Failed to execute 'replaceChild' on 'Node': The node to be replaced is not a child of this node.

Key only works one level deep basically. Where the reconcile and store can diff down to a greater level of detail. I usually go for stores.

7 replies

TTCTheo's Typesafe Cult

•Created by lilak on 3/4/2024 in #questions

How are signals implemented?

Signals are independent of rendering and have a defined behavior that is pretty out in the open. Very what you see is what you get. There are tradeoffs to that as you need to be aware of function wrappers a bit. But on the magical scale I'd say we are the least magical.

29 replies