Is there a good reason to introduce a new concept instead of detecting if a standard component has no methods/properties except for the template and doing the optimisation to turn it into this?

var Demo = template(`{{@value}}`, { scope: () => ({}) });

I was thinking the same thing as @evoactivity. Would be cool if we eliminated the template only paradigm entirely, everything is class based, then the class is optimized away when not needed. This is clearly way more complicated on the build, but I've heard from more than one person that the ember/no-empty-glimmer-component-classes rule is annoying as you don't really know when you get started with a component if you're going to need the backing class or not and there is a temptation to disable that rule.

This rule is currently the only thing preventing me from doing this accidentally, and I'm glad for the rule, but it does point to a place where the mental model for components conflicts with the realities of build and performance. This RFC seems to point the same way.

I mean, I think that's a great idea, and it means we only need to teach about a "for fun" detail that folks normally don't have to worry about.

I like that better than what's written here and will update the RFC text to reflect

Actually, I don't think that's possible without a breaking change.

Consider:

class A extends Component {
  <template>
     <B @state={{this}} />
  </template>
}

class B extends Component {
  get router() {
    return getOwner(this.args.state).lookup('...');
  }
  <template>
    {{this.router.currentURL}}
  </template>
}

Now... should someone do this? absolutely not. lol
But folks could be doing it today, for less silly reasons than the above example, and converting class A to a template-only component would break their apps.

So naturally, we could say something more specific about the logic that governs when class A would be converted to a template only component -- by saying that this cannot be referenced in the template as well.

This requires that we fully parse the template contents during compilation -- which we currently don't do. The conversions to low-level template() format for A would look like this:

class A {
  static {
    template(`<B @state={{this}} />`, { 
      component: this,
      scope: () => ({ B }) 
    });
  }
}

as proposed, we would ignore the component: this line, that's fine, but normally we leave the first arg passed to template() a string (for libraries).

So, this means only applications would get this optimization, as only in applications (where we would parse and compile the template anyway), could we determine if a this Path exists, and then decide to replace the whole class with a var A = template(....)

Is this an ok trade-off?

Would be cool if we eliminated the template only paradigm entirely

@jrjohnson I don't think we need to elimate the paradigm entirely since this is still useful

const rowComp = <template><div>I'm row {{@data}}</div></template>; // <-- template only

class ThingWithRows extends Component {
  rows = [...Array(20).keys()].map( i => i+1); ;

  <template>
    {{#each rows as |row|}}
      <rowComp @data={{row}} />
    {{/each}}
  </template>
}

This requires that we fully parse the template contents during compilation -- which we currently don't do.

@NullVoxPopuli Could we just look in the string for any occurrence of this inside of {{ }} using regex to avoid parsing it fully? If not the trade off sounds reasonable.

I'm ok with this tradeoff, mainly because I think if you're authoring an add-on or some other way to include components into the application it's reasonable to assume you are willing to learn more stuff. But this difference between authoring an app and an add-on can get really difficult quickly. So it's probably not a great path to take unless we can lint the difference and encourage the behavior needed.

I'm also wondering if we need to look all the way into the <template>. I'm not sure, but would it be possible to determine if a component class only included the template itself and nothing else? Would this make it possible to eliminate the difference and the tradeoff? edit: ah I see, you're passing this elsewhere. Got it.

We certainly don't need to eliminate the const style, but I'd say that the template only const declaration is instead an additional authoring method for that special case and completely available if needed in other places. This is the inverse of the way Octane had us thinking (start with his), but I like the concept for teaching. You always start with a class and then you can add const template stuff as well.

Could we just look in the string for any occurrence of this inside of {{ }} using regex to avoid parsing it fully?

I thought about that as well, but regex is hard, and it's why the v3 version of ember-template-imports was so buggy.

Situations that'd be hard to deal with with regex:

• {{
   this
  
  
  }}

• {{concat "}}" this }}

• @arg={{"this"}}

@NullVoxPopuli this monstrosity seems to work in many cases but I take your point

{{(?=(?:[^"'{}]|"[^"]*"|'[^']*')*?\bthis\b(?:[^"'{}]|"[^"]*"|'[^']*')*?\}\})(?:[^"'{}]|"[^"]*"|'[^']*')*?\bthis\b(?:[^"'{}]|"[^"]*"|'[^']*')*?}}

https://regex101.com/r/hD8UqN/3

Broke it for you :p https://regex101.com/r/aw8K9W/1

I fixed those cases but it's even worse now. Not exactly maintainable. I will code golf this no more 😄
https://regex101.com/r/aw8K9W/2

wrote up a new one: #1134

potential alternative:

// current: no generics!
export const Demo = <template>...</template> 

// what Glint would want
// but doing this would require a component manager that hijacks all functions in component space
// (or we compile it away and forbid anything other than the <template></template>)
export function Demo<T>() {
  return template(``)
}

// but our runtime is the equiv of
export const Demo = template('...');

// author-time???
export const Demo = <template type:{
  <T extends Record<string, unknown>, K extends keyof T>() => {
    Element: HTMLTextAreaElement;
    Args: {
      foo: T;
      bar: K;
    },
    Blocks: {
      default: []
    }
  }
}>...</template>