JS Representation of Template Tag

[ef4]

Rendered

[chriskrycho]

Is the intent here to ~upstream the type from @glint/template, or otherwise to provide it from a new @glimmer/template package?

[ef4]

Sorry, just a typo, that was supposed to say @glint/template.

But also: is that OK? I understand that a lot of that package calls itself private, but it also seems like the best type we have for this purpose.

[chriskrycho]

Ah, very good. Yes, that specific import is explicitly public and intended for this sort of usage! The only concern we will want to think about is that it forces a consideration for co-evolution of these packages, but that’s largely already true and we also expect the public API here to be quite stable so that’s not a particularly significant concern.

[chriskrycho]

Per the examples above, I notice that the return type is unused in the case of a class-backed component, so what's the reason to have it be returned there?

import { template } from "@ember/template-compiler";
 class Example extends Component {
   static {
     // ❗️ return value is unused ❗️
     template(
       "Hello {{message}}",
       {
         scope: () => ({ message }),
       },
       this
     );
   }
 }

Note that I am not objecting, just observing and curious what your thoughts here are.

[chriskrycho]

This signature is actually forbidden by TS: you cannot pass a required param after an optional param.

[ef4]

This was also a typo, I should have removed the ? when I split the definition into the two overrides.

Although your other suggestion to reorder these would also probably be fine too.

[chriskrycho]

Two notes on this type:

1. Note: the union will allow you to pass both eval and scope. playground. We have a choice to make here:

   • Do we indulge in some type-level shenanigans to forbid it?
   • Or do we just ship a lint rule or some such?

   I think either case is fine, since this is a low-level API which is mostly emitted by tools.

2. I think we want the callback signature to get an instance where there is a class, and no argument at all (or, for consistency with the current runtime behavior, null?) when there is no class passed?

Combining those two notes, I think our final signature here should look something like the one in this playground, which makes the following changes:

1. It moves the class argument before the params to avoid the issue with optional params preceding required params.
2. It introduces a StrictUnion type to force excess property checking to do what we would expect so you cannot pass both scope and eval.
3. It updates the return type from eval to be unknown instead of any. While eval() itself returns any, this means our own code is stricter and safer here.
4. It passes no argument at all to the scope in the case of template-only components, and passes the instance type scope in the case of class-backed components.

[ef4]

Thanks, this is great.

[ef4]

I hit a snag with the idea to reorder the parameters. When the call arity is two, we need to distinguish the case where the second argument is a parameters bag vs a backing class. And I'd rather not make a lot of assumptions about what's inside a component. Maybe it even happens to have a property named scope, etc.

Perhaps instead we should move the backing class inside the params bag. Only downside I see is that it's slightly more wordy, since it will need a property name.

[chriskrycho]

That was the other thought I had. Otherwise, making the params argument required in both cases also works—and seems fine from the POV that this is a low-level API primarily for tools and secondarily for authors doing relatively low-level work.

[chriskrycho]

Overall 👍🏼 from me on the API direction; left a detailed note on the types here to make them work the way you want them to!

[wagenet]

Just moved to FCP!

[kaermorchen]

Hi all!

How will private fields work in children components?
For example:

class A extends Component {
  name = 'A';
  #privateField = 42;
  <template>A am {{this.name}} {{this.#privateField}}</template>
}

class B extends A {
  name = 'B';
}

Will component B render privateField? Can private fields in templates make some sort of non-obvious behavior?

[ef4]

I think the inheritance case should behave just like typical JavaScript. The template is lexically scoped inside the parent class, so it has access. The child doesn't have access. The child can still use the parent's template, but if the child overrides the template it can only refer to public (or in typescript terms, protected) fields.

If you think of the template as similar to a method it would be the same. The method in the parent has access, the child can call the method, but if the child overrides the method the child's implementation can't gain access.

[flashios09]

Hi,
does this mean we will be able to use valid js/ts without needing the gjs/gts extension ?
the template() function could be used instead of the <template /> angle brackets ?

[chriskrycho]

Yes… but that’s already true of the compilation format this will supersede, too. It’s not particularly ergonomic, though:

• Every single thing you reference in your template will have to be manually named in the scope object.
• There is not syntax highlighting for it and it’s unlikely anyone will develop it.
• We will not be providing Glint support for it (since it is a low-level format not intended for normal authoring).
• There will not be any Prettier or ESLint or ember-template-lint support for it.

…all of which also already apply to the target format which this would supersede. You won’t get any of the benefits of the custom syntax, in other words!

[lifeart]

Some things to highlight from https://twitter.com/nullvoxpopuli/status/1665462066960912387

• At the moment there is no real-life use-case for private property access inside templates.
• We still not support [string properties like this], and such cases should be accessed using get helper.
• If property is defined via symbol, we also have to use get helper and symbol reference.
• We already use get helper for array by-index access.

So, private property access may be also available only via get helper (if needed). But I do see lack of real-life use-cases for private properties in components. It may be absolutely valid inside libs (glimmer/starbeam), services, business logic classes and cetra, but for view layer it's looks really strange.

Concerns have been addressed.