Update Glimmer Template Truthiness Semantics

[bakerac4]

Rendered

Provide a path for Glimmer templates to switch away from classic Handlebars truthiness to JavaScript’s truthiness. This will align our templating language with users' expectations and make teaching easier. It will also allow TypeScript features like type narrowing to work as users would expect it to with keywords like {{and}} or {{or}}.

[boris-petrov]

I'm confused, is this connected to this issue? Isn't updating these semantics going to break billions of apps?

[chriskrycho]

1. No, because assuming we do this, we are going to have a migration plan that allows the community to migrate incrementally.
2. Billions of apps 🤣

[wagenet]

Looks great overall. Beyond my comments, I think there's a bit more minor editing work than can be done, mainly around consistent capitalization of JavaScript and TypeScript.

[chriskrycho]

We talked a little bit about this at a high level at the Framework team meeting today (everyone is excited), and I'll review it early next week with the input from that!

[jelhan]

Thanks a lot for this RFC! I'm very much in favor of following native JavaScript more closely.

[jelhan]

How would that opt-in look like? Would be great if you could do more in detail for the migration story in general.

[bertdeblock]

Should {{not}} also error when invoked with no arguments?

[bakerac4]

Not that this means anything, but according to the original RFC no? https://rfcs.emberjs.com/id/0562-add-logical-operators.

But that does bring about the question of what they were expecting to happen in that case? In my opinion, it would make sense to error there.

Edit: After playing around in a console I might have changed my mind. !undefined = true. And since we want to keep the semantics equal to Javascript - it might make sense to return true in this case?

[wagenet]

Maybe still strange? I'm unsure. We definitely should support {{not undefined}} but I'm not sure about {{not}}.

[jelhan]

I would tend to not throw if invoked without arguments ({{(not)}}). But from typing perspective the argument should be required. And we might want to have a linting rule forbidding argumentless {{(not)}}.

I don't see much value in throwing. Implementation complexity should be the same. But we should use types and linting to push people towards {{false}} instead.

[wagenet]

I like @jelhan's solution here.

[wagenet]

We should discuss what it takes for us to accept this at the next RFC Review.

[ef4]

Two main bits of feedback:

1. We need a more detailed migration plan. Does this use optional-features? Is the opt-in per-package or global? If it's global, how are people realistically supposed to upgrade without breaking their addons? What are addon authors supposed to do (they can't control when their consuming apps flip a global opt-in)? If it's per-package, how does that actually work at runtime (is there something visible in the actual compiled templates to say "this one uses the new boolean semantics"?).

2. An important "Alternatives" topics is the idea of adding Javascript expression syntax to templates, something that we've discussed at length and people generally like as an idea, though no written design exists yet. Since that would also introduce new replacements for truth helpers, ones that would necessarily have javascript semantics, it seems like an area of overlap and it could make doing this RFC easier if we also did that one.

I have to say, I've been working in Glint quite a lot already and I've yet to hit a realistic example where this semantic gap actually came up. I would be curious to see people's examples. That doesn't mean I don't care about closing it, but I do think it's relevant to how we teach this and how we prioritize the migration.

[chriskrycho]

The places it's likely to come up are exceptionally rare, but likely to be very annoying for people when they do happen, just insofar as they're a case where TS/Glint tells you they're safe and then you get a runtime error from it. Implicit in @ef4's comment is that Glint does let folks opt in (and our docs will better reflect that hopefully this week!).

That said, using a JS-expression-syntax would also solve this, and has the possibility a clear and straightforward opt-in at a template authoring level (e.g. a <template lang='something-good-here'> or some such along with an optional-feature to flip the default), and cleanly solves the problem from a Glint POV because there is no problem in that world: you just get TS semantics for free. Given the likely non-trivial work of migrating the truthiness semantics of existing Handlebars vs. switching to a JS expression syntax, my own personal preference would be extremely strongly toward the latter.

[wagenet]

We should hash through this at the next feature design meting.