I'm a big fan of this, as this is the baseline to write a storybook adapter for gts files. But I have some questions around this, as I think the narrative is not clear (yet):

1. Why is it renderComponent() ... when it renders a template? (which I very much prefer). We can use that to render html that uses a helper or modifier. Vue and svelte have similar concepts for helper and modifier, but their testing lacks support for them, because they constrained themselves to components only (see my Inline Svelte components for tests sveltejs/svelte#14791 (comment), alse see API for vitest-browser-svelte and vitest-browser-vue) and I like us not to run into that constrained. I see it similar to the render() function we use in tests and would even expect the same behavior.

2. There is args but no backing class? That means a template-only-component? Is that by-design?

3. I wonder why there is an into parameter and later a parentElement() on the result type? If into becomes the parentElement then please name it like that (or is it the render replacing the into). Is the parentElement() on the result then needed? We can assume that is a given?

4. There is plenty API that adressess templates, but this is also very much fragmented. Can we all the API that is about templates in @ember/template? In the end it doesn't really matter if these are compilers or renderers or parsers or whatever. In the end everything that you need to operate on templates is coming from one package.

Why is it renderComponent() ... when it renders a template?
There is plenty API that adressess templates, but this is also very much fragmented. Can we all the API that is about templates in @ember/template

template() only returns a component 🎉
when not used with a class, it returns a template-only component.

I see it similar to the render() function we use in tests and would even expect the same behavior.

aye! the render() utility from @ember/test-helpers is quite involved, and after this RFC we could change its implementation to use renderComponent to

• simplify implementation of @ember/test-helpers / ember-qunit
• encourage exploration of other render-utilities, such as what would be needed to make browser-mode vitest work

There is args but no backing class? That means a template-only-component? Is that by-design?

what do you mean no backing class?

This is covered in RFC#931

import { template } from "@ember/template-compiler";

class Example extends Component {
  static {
    template(
      "Hello {{message}}",
      {
        component: this,
        scope: () => ({ message }),
      },
    );
  }
}

s the parentElement() on the result then needed? We can assume that is a given?

I only included it because the sample implementation from @wycats included it -- I'm more than happy to remove it, as it does feel redundant, since you need a handle to that same element (it is the into) to render anything anyway.

A good question brought up by @void-mAlex at RFC review: what happens if you call renderComponent multiple times with the same Element? Is that allowed?

A good question brought up by @void-mAlex at RFC review: what happens if you call renderComponent multiple times with the same Element? Is that allowed?

update pushed!

Clarification has been added around the calling-multiple-times-on-the-same-element behavior, and during the RFC review meeting, since FCP is passed, we decided to merge -- I'll now head over to implementing -- yay!

finished the implementation here: emberjs/ember.js#20962