[Bug?]: client only doesn't work anymore for `props.children` about solid-start HOT 6 CLOSED

There's some bad patterns here, but mainly I'd just recommend using this component:

import { createSignal, onMount, Show } from 'solid-js';

function ClientOnly(props) {
  const [flag, setFlag] = createSignal(false);
  
  onMount(() => setFlag(true));
  
  return <Show when={flag()}>{props.children}</Show>;
}

(or just install solid-use and use solid-use/client-only)

But to explain why your usage is wrong:

1. Client-only is meant to be used with a dynamic import. Without the dynamic import, you are still loading the component's module on the server-side.
2. Your ternary condition still renders the props.children without guaranteeing that it renders only on the client-side.
3. Your client-only factory would be the reason why it's triggering an infinite loop. It's just a pattern that you should not do.

from solid-start.

@lxsmnsyc Thanks for your help makes sense, maybe we should add something like a ClientOnlyBoundary in future, to make this clear. Unfortunately the current solid start documenation is quite bad when it comes to advanced requirements.

from solid-start.

The reason clientOnly was implemented first was because of the fact that there are libraries that provides a client-only side-effect, which triggers errors when imported on the server. clientOnly forces the user to import these dynamically to prevent the modules from being loaded immediately.

from solid-start.

Ok, I see, but that doesn't mean, that a ClientOnlyBoundary component wouldn't be useful. I think that such small util functions that directly work together with the solid start engine (I would call it) should be provided by solid-start for convenience. And this would be a nice addition.

from solid-start.

Understanding this issue, I think this is no action. As @lxsmnsyc responded clientOnly is for dynamic imports. ClientBoundary is interesting but it is also another thing. When it is an official component we have to explain when to use one over the other. It's one of those cases where while it could be made into another component, it could be done more specifically for the situation in a number of ways and it is minimal code. I see solid-use has a prebuilt of it so it is readily available. Which makes me more inclined to defer any action on this until it is clear where the responsibility for this should lie.

from solid-start.

Makes sense, thanks for your detailed answer

from solid-start.