Support setting properties with non-primitive values on custom elements

[nwhittaker]

In Ember, given the snippets:

class MyElement extends HTMLElement {
  myObjProp = { a=0, b=0 }
}

<my-element myObjProp={{hash a=1 b=2}} />

The MyElement.myObjProp property gets set to { a: 1, b: 2} without problem. However, Glint fails on the line in the template with:

Type '{ a: number; b: number; }' is not assignable to type 'AttrValue'.
Object literal may only specify known properties, and 'a' does not exist in type 'SafeString'.glint:ts(2322)

The error message suggests Glint is treating myObjProp as an attribute rather than a property.

I'm not familiar with Ember's internals, but the behavior I see is that it tries to set the value of a property on the component before falling back to passing the value to the component as an attribute. Any way for Glint to allow setting a component's property with a complex type?

[dfreeman]

it tries to set the value of a property on the component before falling back to passing the value to the component as an attribute

This is true of how Ember handles both web components and native elements, but it's a behavior the framework team has talked for a long time about wanting to deprecate. This post has some details on exactly how the heuristic works, and the strict-mode RFC mentions the plan to move to "attribute syntax always means attributes" semantics for templates (though not as part of strict mode).

There's a currently-inactive "HTML Attribute and Property Rationalization" RFC that proposes doing away with the prop-vs-attr heuristic behavior, but that wound up stalling out: first because of the desire for general-purpose userspace modifiers, and then because those modifiers don't have access to custom elements early enough in their lifecycle for some use cases. However, there's now an active RFC to cover that, which would give modifiers the ability to act on an element before it's inserted into the DOM.

All of that is to say: currently Glint's restriction on passing non-primitive values as DOM attributes is intentional based on the stated goals of the framework team for future template semantics. In an ideal world, your invocation above would probably look something more like this:

<my-element {{props myObjectProp=(hash a=1 b=2)}} />

By adding an entry to the built-in HTMLElementTagNameMap interface, you would even get full type safety on that invocation, assuming props had a signature something like this:

interface PropsSignature<E extends Element> {
  Element: E;
  Args: {
    Named: Partial<E>;
  };
}

However, if for performance or correctness reasons your component needs all props assigned before its connectedCallback is invoked, then something like {{props}} probably isn't viable until the modifier timing RFC I mentioned above lands. Additionally, the fact remains that the snippet you posted does work today, even if there's a future where it may not.

Given the above, I can see a few paths we might take in Glint (not all mutually exclusive):

• Advocate to move RFC 883 forward as quickly as possible and then guide developers toward using modifiers to handle setting custom element properties
• Document that developers should use {{! @glint-expect-error }} when passing non-primitive values as "attributes" to custom elements
• Update our internal handling to treat custom elements specially and allow passing arbitrary data via "attributes" on them, with the caveat that you're own your own for type safety.

What are your thoughts, @jamescdavis @chriskrycho?