Make the `on` modifier built-in in strict-mode #997

NullVoxPopuli · 2023-12-22T19:01:32Z

Propose making `{{on}}` a built in modifier

Rendered

Summary

Today, we need

import { on } from '@ember/modifier'`;

This should be built in, and not require an import.

An FCP is required before merging this PR to advance to Accepted.

Upon merging this PR, automation will open a draft PR for this RFC to move to the Ready for Released Stage.

Exploring Stage Description

This stage is entered when the Ember team believes the concept described in the RFC should be pursued, but the RFC may still need some more work, discussion, answers to open questions, and/or a champion before it can move to the next stage.

An RFC is moved into Exploring with consensus of the relevant teams. The relevant team expects to spend time helping to refine the proposal. The RFC remains a PR and will have an Exploring label applied.

An Exploring RFC that is successfully completed can move to Accepted with an FCP is required as in the existing process. It may also be moved to Closed with an FCP.

Accepted Stage Description

To move into the "accepted stage" the RFC must have complete prose and have successfully passed through an "FCP to Accept" period in which the community has weighed in and consensus has been achieved on the direction. The relevant teams believe that the proposal is well-specified and ready for implementation. The RFC has a champion within one of the relevant teams.

If there are unanswered questions, we have outlined them and expect that they will be answered before Ready for Release.

When the RFC is accepted, the PR will be merged, and automation will open a new PR to move the RFC to the Ready for Release stage. That PR should be used to track implementation progress and gain consensus to move to the next stage.

Checklist to move to Exploring

The team believes the concepts described in the RFC should be pursued.
The label S-Proposed is removed from the PR and the label S-Exploring is added.
The Ember team is willing to work on the proposal to get it to Accepted

Checklist to move to Accepted

This PR has had the Final Comment Period label has been added to start the FCP
The RFC is announced in #news-and-announcements in the Ember Discord.
The RFC has complete prose, is well-specified and ready for implementation.
- All sections of the RFC are filled out.
- Any unanswered questions are outlined and expected to be answered before Ready for Release.
- "How we teach this?" is sufficiently filled out.
The RFC has a champion within one of the relevant teams.
The RFC has consensus after the FCP period.

text/0997-make-on-built-in.md

Co-authored-by: MrChocolatine <47531779+MrChocolatine@users.noreply.github.com>

NullVoxPopuli · 2023-12-24T22:31:41Z

text/0997-make-on-built-in.md

+
+This change would affect strict-mode only. This is so that today's existing code that imports `on` from `@ember/modifier` will still work due to how values defined locally in scope override globals.
+
+The behavior of `on` would be the same as it is today, but defined by default in the `glimmer-vm`.


turns out, on is already in glimmer-vm: https://github.com/emberjs/ember.js/blob/main/packages/%40ember/modifier/index.ts#L19

NullVoxPopuli · 2023-12-27T15:08:35Z

text/0997-make-on-built-in.md

+
+## Alternatives
+
+n/a


An alternative (or maybe working in conjunction with), is adopting svelte-like syntax

<template> <button on:click={{fn play #video}}> Play </button> <video #video src={{@url}} /> </template>

but that would probably need to be a separate RFC entirely

NullVoxPopuli · 2024-02-16T23:21:46Z

text/0997-make-on-built-in.md

+- Use a prelude
+    - preludes were mentioned during the initial exploration of strict-mode templates, and were decided against, because addons would not be able to assume a prelude exists, as apps could define their own, and this sort of re-introduces the app-tree-merging behavior that we've been trying to get away from. 
+
+- Use an alternate syntax: `on:click={{handler}}` or `on:{eventname}={{value}}`


Techn1x · 2024-02-17T06:29:21Z

I like this. Seems simple enough, there's already precedent from other modifiers. Isn't really anything new to learn. Could even add a fixable template lint rule to remove unneeded import lines.

jelhan · 2024-02-17T17:51:43Z

text/0997-make-on-built-in.md

+
+## Summary
+
+Today, when using gjs/gts/`<template>`, in order to bind event listeners, folks _must import_ the `{{on}}` modifier.


This is not true as discussed in #1007. Folks could also use the on* properties of the element.

Given the discovery of onclick's usefulness for the use case that I'm mostly thinking about with this RFC, I think I may even need convincing for this RFC to be pursued.

Related decision chart: #1007 (comment)

yes but that has nothing to do with this proposal, you can always use normal html attributes

I just mean, that because of onclick (and similar), I'm not sure we need This (RFC #997) at all -- but instead may want to teach folks to use onclick (and related) rather than {{on}} for everything

you can always use normal html attributes

My main concerns with <button onclick={{foo}}> is that it looks as setting attributes while actually setting a property.

But I fear that's a little bit off topic here. 🙃

jelhan · 2024-02-17T17:53:51Z

text/0997-make-on-built-in.md

+
+Once implemented, the guides, if they say anything about gjs/gts/`<template>` and `on` by the time this would be implemented, would only remove the import.
+
+## Drawbacks


Adding {{on}} to template syntax rather than importing explicitly would complicate upgrade path to alternative patterns later. #1007 shows that even for basics such as {{on}} modifier we shouldn't take for granted that it will be still best practice in 3-5 years.

how would it complicate upgrades?

achambers · 2024-03-13T15:39:56Z

Makes sense to me.

achambers · 2024-03-27T15:24:30Z

text/0997-make-on-built-in.md

+
+## How we teach this
+
+Once implemented, the guides, if they say anything about gjs/gts/`<template>` and `on` by the time this would be implemented, would only remove the import.


Suggested change

Once implemented, the guides, if they say anything about gjs/gts/`<template>` and `on` by the time this would be implemented, would only remove the import.

Once implemented, the guides, if they say anything about gjs/gts/`<template>` and `on` by the time this would be implemented, would only remove the import.

The guides should also detail which functions are built in to the framework and, therefore, do not need to be imported.

achambers · 2024-03-27T15:26:10Z

RFC Review (1) are in favour of this.

kategengler · 2024-05-17T18:40:05Z

We decided to move this RFC along with #998, #999, #1000 into FCP to accepted today at the RFC meeting.

make on built in

348e0ab

github-actions bot added the S-Proposed In the Proposed Stage label Dec 22, 2023

NullVoxPopuli added 3 commits December 22, 2023 14:13

Tweak some boilerplate

3190055

Add summary and motivation

0155361

Draft done

02cf0cf

NullVoxPopuli changed the title ~~make on built in~~ make on built-in in strict-mode Dec 22, 2023

MrChocolatine reviewed Dec 23, 2023

View reviewed changes

text/0997-make-on-built-in.md Outdated Show resolved Hide resolved

Update text/0997-make-on-built-in.md

2d1ccf7

Co-authored-by: MrChocolatine <47531779+MrChocolatine@users.noreply.github.com>

NullVoxPopuli commented Dec 24, 2023

View reviewed changes

NullVoxPopuli commented Dec 27, 2023

View reviewed changes

kategengler changed the title ~~make on built-in in strict-mode~~ Make the on modifier built-in in strict-mode Dec 27, 2023

ef4 added the S-Exploring In the Exploring RFC Stage label Jan 19, 2024

fivetanley mentioned this pull request Jan 24, 2024

[bugfix] allow modifier helper to resolve built-ins like on emberjs/ember.js#20629

Open

NullVoxPopuli mentioned this pull request Feb 9, 2024

EmberTimes no. 209 ember-learn/ember-blog#1326

Merged

5 tasks

kategengler removed the S-Proposed In the Proposed Stage label Feb 9, 2024

NullVoxPopuli added 2 commits February 16, 2024 15:32

Updates

8dd13de

Updates

73067d5

NullVoxPopuli mentioned this pull request Feb 16, 2024

maybe, maybe not better on syntax - this RFC accidentally found some decision trees around when to use {{on}} vs on* #1007

Closed

11 tasks

NullVoxPopuli commented Feb 16, 2024

View reviewed changes

jelhan reviewed Feb 17, 2024

View reviewed changes

Add another drawback

9e61c0b

achambers reviewed Mar 27, 2024

View reviewed changes

kategengler added the Final Comment Period label May 17, 2024

This was referenced May 17, 2024

Make fn built-in in strict-mode #998

Merged

Make array built-in in strict-mode #1000

Merged

Make hash built-in in strict-mode #999

Merged

achambers enabled auto-merge June 12, 2024 14:20

achambers added 2 commits June 12, 2024 15:20

Merge branch 'master' into make-on-built-in

6733ac3

Merge branch 'master' into make-on-built-in

f7cdd5d

achambers merged commit 31340d5 into emberjs:master Jun 12, 2024
8 checks passed

emberjs-rfcs-bot mentioned this pull request Jun 12, 2024

Advance RFC #0997 "Make {{on}} a built in modifier" to Stage Ready for Release #1033

Draft

8 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make the `on` modifier built-in in strict-mode #997

Make the `on` modifier built-in in strict-mode #997

NullVoxPopuli commented Dec 22, 2023 •

edited by achambers

Loading

NullVoxPopuli Dec 24, 2023

NullVoxPopuli Dec 27, 2023

NullVoxPopuli Feb 16, 2024

Techn1x commented Feb 17, 2024

jelhan Feb 17, 2024

NullVoxPopuli Feb 17, 2024

void-mAlex Feb 17, 2024

NullVoxPopuli Feb 17, 2024 •

edited

Loading

jelhan Feb 17, 2024

jelhan Feb 17, 2024

NullVoxPopuli Feb 17, 2024

achambers commented Mar 13, 2024

achambers Mar 27, 2024

achambers commented Mar 27, 2024

kategengler commented May 17, 2024


		This change would affect strict-mode only. This is so that today's existing code that imports `on` from `@ember/modifier` will still work due to how values defined locally in scope override globals.

		The behavior of `on` would be the same as it is today, but defined by default in the `glimmer-vm`.


		## Summary

		Today, when using gjs/gts/`<template>`, in order to bind event listeners, folks _must import_ the `{{on}}` modifier.


		Once implemented, the guides, if they say anything about gjs/gts/`<template>` and `on` by the time this would be implemented, would only remove the import.

		## Drawbacks


		## How we teach this

		Once implemented, the guides, if they say anything about gjs/gts/`<template>` and `on` by the time this would be implemented, would only remove the import.


		## Alternatives

		n/a

Make the on modifier built-in in strict-mode #997

Make the on modifier built-in in strict-mode #997

Conversation

NullVoxPopuli commented Dec 22, 2023 • edited by achambers Loading

Propose making {{on}} a built in modifier

Summary

Checklist to move to Exploring

Checklist to move to Accepted

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Techn1x commented Feb 17, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

NullVoxPopuli Feb 17, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

achambers commented Mar 13, 2024

Choose a reason for hiding this comment

achambers commented Mar 27, 2024

kategengler commented May 17, 2024

Make the `on` modifier built-in in strict-mode #997

Make the `on` modifier built-in in strict-mode #997

NullVoxPopuli commented Dec 22, 2023 •

edited by achambers

Loading

Propose making `{{on}}` a built in modifier

NullVoxPopuli Feb 17, 2024 •

edited

Loading