Make (fn) a built in helper
Summary
Today, when using gjs/gts/<template>, in order to bind event listeners, folks must import the (fn) helper.
Because partial application is so commonplace, this is a grating annoyance for developers.
This RFC proposes that (fn) be built in to glimmer-vm and not require importing.
Motivation
There is precedence for fn being built in, as all the other partialy-application utilities are already built in.
(helper)(modifier)(component)
It's historically been the stance that,
"If it can be built in userspace, it should be, leaving the framework-y things to be only what can't exist in userspace"
But to achieve the ergonomics that our users want, we should provide a more cohesive experience, rather than require folks import from all of (in the same file):
@glimmer/component@glimmer/tracking@ember/modifier@ember/helperember-modifierember-resourcestracked-built-ins
Some of the above may unify in a separate RFC, but for the template-utilities, since the modules that provide them are already so small, it makes sense to inherently provide them by default. Especially as we can target strict-mode only, so that we don't run in to the same implementation struggles that built-in Logical Operators, Numeric Comparison Operators, and Equality Operators have faced.
some context on those RFCs
The main problem with adding default utilities without strict-mode is that it becomes very hard to implement a way for an app to incrementally, and possibly per-addon, or per-file, to adopt the default thing due to how resolution works. Every usage of the built in utility would also require a global resolution lookup (the default behavior in loose mode templates) to see if an addon is overriding the built ins -- and then, how do you opt in to the built ins, and not let addons override what you want to use?
With gjs/gts/<template>, this is much simpler, as in strict-mode, you can check if the scope object defines the helpers, and if not, use the built in ones.
This strategy of always allowing local scope to override default-provided utilities will be a recurring theme.
Making fn a built-in will help make writing components feel more cohesive and well supported, as folks will not need to cobble together many imported values
Detailed design
This change would affect strict-mode only. This is so that today's existing code that imports fn from @ember/helper will still work due to how values defined locally in scope override globals.
The behavior of fn would be the same as it is today, but defined by default in the glimmer-vm.
fn will be a keyword, and for backwards compatibility, this will require that keywords, in strict mode, be overrideable by the strict-mode scope bag.
How we teach this
Once implemented, the guides, if they say anything about gjs/gts/<template> and fn 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.
Drawbacks
People may not know where fn is defined.
- counterpoint: do they need to?, we are defining a lanugage, trying to make it ergonomic.
Alternatives
- 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.
Unresolved questions
- What happens if we want to remove a keyword? (like
mut) - same as today, we only need to commit to a major to remove the keyword in and then do it - providing ample deprecation time, ending with the final removal.