Possibility of a portal?

[rakshith-ravi]

Possibility of a portal?

[maccesch]

I researched a bit and it seems that React as well as SolidJS both have that as part of the core framework. After glancing over the SolidJS implementation however I think there's nothing that requires a deep integration. I kind of want to implement it. I might create a PR in leptos directly

[rakshith-ravi]

Sure. That works too. For reference, there's a working implementation here - https://github.com/jquesada2016/leptos-declarative
(CC @jquesada2016) I don't fully understand how it works, but it has a few bugs and my efforts to contact the maintainer has been in vain. I'm also not sure if or when it will be updated to 0.5.0. If this can be included in core leptos, that'd be amazing.

Perhaps the initial implementation there could be of some help for you?

[jquesada2016]

@rakshith-ravi sorry for not being on top of this. I've been very busy trying to find a new job and have not had much time to work on any of my repos. I had intended to pull the <Portal /> component into leptos directly, but never got around to doing so. I'm sure @gbj would be open to this!

[rakshith-ravi]

No worries :)

Thank you for your contribution to OSS :D

[gbj]

My one question here would be whether <Portal/> requires any deeper integration for server rendering.

Special components like <Suspense/> and <ErrorBoundary/> that require messing with the top-down flow are the source of most medium-sized bugs at this point. I imagine <Portal/> might also be in the "useful but requires some additional framework support" category.

I've never used <Portal/> in any framework to be clear.

Although now looking at the Solid SSR implementation for Portal suggests one might just... ignore it for SSR? Lol

export function Portal(props: { mount?: Node; useShadow?: boolean; children: JSX.Element }) {
  return "";
}

[jquesada2016]

@gbj I would strongly encourage ignoring it for SSR lol

Nevertheless, for SSR it can be done by using a backing <Resource /> that renders at the very end of the SSR render, and then spliced in via an Arc. Here, the <Resource /> would wait for the end of the render pipeline, which would resolve to the result of the portal.

Does this make any sense at all?

[rakshith-ravi]

Ehh, how the heck did I miss this conversation?

Anyways, @gbj - I think ignoring it for SSR makes sense, considering portals are usually used for rendering things at runtime (think - a tooltip / toast that pops up in the middle of nowhere in the DOM without a proper tree). So having this ignored during SSR should be fine for most users. In case someone specifically needs it rendered on the server, we can always look into more complex implementation as and when people need it

[maccesch]

Totally agree. I actually started implementing this very similar to how SolidJS does it. But I don't think I'll be able to finish before 0.5.0 is released.

[rakshith-ravi]

I think for 0.5 we can have it as a part of leptos-use and battle test it, and once we have figured out the DX / UX of it we can upstream it for 0.6?

This way we know that whatever goes into upstream would be something we have tried and tested, reducing the possibility of a breaking change upstream.

Thoughts?

[maccesch]

I think this really should be in leptos proper in any case. Closing this in favor of the PR.