@mhamri as Ryan stated in a similar issue a while back – the children are already resolved at this point, meaning those are regular DOM elements already so all you can do from there is only DOM manipulations. Please, refer to this issue for more info.

I'd also like to add smth about the children() helper as the docs state at the very bottom:

An important aspect of the children helper is that it forces the children to be created and resolved, as it accesses props.children immediately.

It means that for your example, right after const c = children(() => props.children); the children will be already created and resolved, leaving you again only with DOM manipulations at that point. The last paragraph of the helper's docs explain how you can prevent that instant resolvement.

––––––

One way to achieve your goal would be to pass components as a so-called-in-a-react-world "render function" to a Dynamic component like this: https://playground.solidjs.com/anonymous/450210e2-c5e5-418c-abd6-5368d2718d57

This is a regular way of conditional rendering of the custom components in Solid: https://docs.solidjs.com/concepts/control-flow/dynamic

I understand the current capabilities for handling children, but I've encountered a common scenario that feels difficult to implement elegantly in Solid. My goal is to use child components as a declarative configuration for a parent, rather than just as content to be rendered as-is.

Imagine a Layout component that needs to change its structure based on the screen size. The ideal developer experience (DX) would be to write something clean and declarative like this:

<Layout mode="mobile">
    <Layout.Header>Sample Header</Layout.Header>
    <Layout.Menu>
        <Layout.Menu.Item key="1"><a href="/">Home</a></Layout.Menu.Item>
        <Layout.Menu.Item key="2"><a href="/about">About</a></Layout.Menu.Item>
    </Layout.Menu>
    <Layout.Content>
        <h1>Welcome</h1>
    </Layout.Content>
    <Layout.Footer>Sample Footer</Layout.Footer>
</Layout>

The Layout component should be able to introspect its children and rearrange them based on the mode prop:

• Desktop: The Layout.Header and Layout.Menu might be rendered at the top of the page.

• Mobile: The Layout.Header and Layout.Menu should be moved into a separate container, like a slide-out side panel, while Layout.Content and Layout.Footer remain in the main document flow.

The core problem is that the Layout parent receives all its children as an opaque array. It cannot easily identify which child is the Layout.Header, which is the Layout.Menu, and so on. This prevents the parent from selectively re-rendering or rearranging them.

This also means the component's structure isn't guaranteed. A user could mistakenly place the Layout.Footer first, and the component can't enforce the correct order, leading to unexpected results.

// This is possible but should be preventable by the component author
<Layout mode="mobile">
    <Layout.Footer>Sample Footer</Layout.Footer>
    <Layout.Header>Sample Header</Layout.Header>
    {/* ... */}
</Layout>

The existing solutions involve patterns like render props or passing components as props, which harm readability and create a verbose API.
I have options to either
1.Function as Children (Render Props): This is hard to type and clutters the JSX.

<Layout mode="mobile">
  {(mode) => [ /* return components based on mode */ ]}
</Layout>

2. or Components as Props: This is extremely verbose and moves the declarative structure into a series of attributes, which is less intuitive

<Layout
    mode="mobile"
    header={() => <Layout.Header>Sample Header</Layout.Header>}
    menu={() => (
        <Layout.Menu items={[ /* menu items */ ]} />
    )}
>
    {/* ... */}
</Layout>

Both approaches compromise the clean, declarative API that makes JSX powerful. They shift the cognitive load to the end-user, whereas the component author should be empowered to handle this complexity internally.

What's needed is a mechanism for a parent to identify its children by type or key, enabling the creation of powerful and robust component APIs that follow the strategy pattern.

I simplified the example to just demonstrate why parent need to have control when and how the child components get rendered, it's just an example. the point is, parent need that control that at the moment is hard to achieve. I'm asking to simplify that

@mhamri Oh sorry, initially I assumed it was more of a "basics" type of question.
In that case if you're fine with adding extra data-attributes – this might be one way to do it:
https://playground.solidjs.com/anonymous/90ea118a-0657-4bdf-90b6-1ac21c6232e0

Or look at Switch/Match. Match just returns the props object to the parent that does all the work.

It sounds like you have complete control over children. Have them return objects that the parent will process. Props automatically get wrapped if they are reactive so you could basically defer actual rendering until you call props.children within.

I'm going to move this to discussion because it belongs there. I don't think we have an actionable item here (at least yet).