children prop should be callable to add attributes

[Blazzike]

As far as I can tell, there is no easy way of adding attributes to children passed into the parent.

Adding them to a client side render is easy enough, but for SSR beyond parsing the output HTML, I'm not sure how you'd do it.

Currently accessing the children prop results in:

get children() {
  return _$ssrElement("tag", {
    /* attributes */
  }, undefined, true);
}

Instead or rather additionally as not to break compatibility the implementation should look something like the following:

children(...additionalAttributes) {
  return _$ssrElement("tag", {
    /* attributes */
    ...additionalAttributes,
  }, undefined, true);
}

So it can be used like so:

<my-amazing-wrapper>
  {children({
    'data-status': 'OK',
  })}

  {/* or */}
  {children()}

  {/* or */}
  {children}
</my-amazing-wrapper>

Cheers!

Edit: Just realised this is probably best suited for the dom-expressions repo, forgot the transpiler is separate - sorry! Happy to move if needed.

[thetarnav]

I would be great to have some official primitive in solid/dom-expressions for that use.

Kobalte-ui is solving that through a polymorphic <As component="button" {...props}> component and a combineProps primitive. But it requires the component to be passed to As as a factory function, rather than a resolved dom node.
impl: https://github.com/kobaltedev/kobalte/blob/main/packages/core/src/polymorphic/polymorphic.tsx
concept: https://kobalte.dev/docs/core/overview/polymorphism

There is also an interesting experiment in solid-radix for applying attributes to already resolved elements. (like spread that combines attributes instead of overriding them) https://github.com/TrentsPC/solid-radix/blob/main/src/solid/Slot.tsx
But it doesn't work in SSR

[ryansolid]

Yeah it's is tricky because at the time you get them they've already been created. On the client yeah you can modify the DOM. On the server that would basically be string manipulation. Truthfully child introspection is a really awkward pattern for declarative libraries and gets in the way of optimization. Even the React Core team (in React this pattern is more common) considers this a bad pattern and effectively deprecated in their minds. I get the scenarios and the APIs it opens up but I think it requires careful consideration.

Stuff like passing in the factory function is a better pattern in general. I think I'm going to move this into discussions so we can collect ideas here.

[thetarnav]

A primitive for this would be useful for the transition-group as well. Because if user enables appear - wants to animate the initial element enter the page, it works great client-side as the enter-class can be applied in the same frame when the elements are added to the dom. But on SSR the inital enter-class cannot be applied because the elements are just strings, so the elements won't be animated initially unless the user decides to apply initial classes on his own.
Being able to apply classes and other attrs in the server to already resolved nodes would be perfect here as it would keep the api design of transition group very simple and not require any additional wiring by the user.