Default managers

[NullVoxPopuli]

Rendered

Superseded by:

• Default Helper Manager #756
• Default Modifier Manager #757
• Default Component Manager #758

[ef4]

Framework core team discussed this today (with a smaller than usual group, so not everybody was able to give feedback yet).

One piece of feedback was that it would be concerning if these default behaviors were pluggable (because the difference would be quite invisible and hard to google/discover). Reading the RFC more carefully, I think that is not your intention though. You're proposing that these three managers should be the baked-in defaults in Ember, correct?

This RFC may preclude adding plain function components in the future, because there are ambiguous positions like:

{{this.foo 1 2 3}}

Which can be either a component or a helper. If people start invoking plain functions as helpers using this syntax, then we cannot later do: setComponentManager(..., Function.prototype) because that would break all the existing call sites, because having a component manager takes precedence over having a helper manager. Maybe that's OK, but it should be considered and addressed in the RFC.

To resolve potential problems, I think it would be helpful to build a matrix of template positions vs javascript types and explain what happens in each case. Something like:

	typeof val === 'function'	typeof val === 'object'
{{val}}
{{ (val) }}
{{val withSomeArgument}}
<val />
<Component @arg={{val withSomeArg}} />

(although I don't think this is complete, I'm just illustrating the idea)

It's ideal if any combinations we don't want to support yet are errors, as opposed to silently doing something odd.

The RFC should probably consider whether this change will cause confusing error messages when people make typos. For example, if you meant to say:

<Whatever @onClose={{this.handler}} />

And then you try to curry an argument incorrectly:

<Whatever @onClose={{this.handler 1}} />

Today you would get an error about this.handler not being a helper. But after this RFC, the function in this.handler would become a valid helper and we would call it. Which, in bad cases, may even cause an infinite revalidation assertion, which would be pretty confusing.

[NullVoxPopuli]

Thanks @ef4 (and team!)

I think I've addressed all your comments, including adding to the drawbacks sections wherein someone would want to define a function component and invoke it via curlies. This proposal eliminates that possibility, leaving only AngleBracketInvocation for function-components... which... is fine? 🙃

[NullVoxPopuli]

In strict mode, this is a non-issue because ambiguous invocations must be invoked via {{ (this.handler) }}.
But, idk when strict mode is going to be default, or if default managers should be a reward for setting strict mode in your app (optional-feature?) idk

[pzuraq]

We discussed this at todays core team meeting and had a bit more feedback:

1. The default component manager introduces some ambiguities around invoking components vs helpers in the default programming model, e.g. {{myValue 123}} will be invoked using the default helper manager, and <myValue/> will use the default component manager. This type of ambiguity is something that we've been moving away from in general, so we want to think about this in more depth and consider whether or not it makes sense to do this.
2. In light of the previous point, we think it would make sense to split this RFC out into 3 separate RFCs, one for each type of default manager (component, helper, and modifier). This should allow us to focus the discussion for each RFC one at a time, and fast track the RFCs that don't introduce additional ambiguities (helper and modifier).
3. One final thing was that we should think about async and generator functions as helpers - should they have any different type of behavior that standard functions? The answer is most likely that they should be treated just like normal functions, but we want to think that through and it would be good either way to state that explicitly in the RFC.

Thanks again for pushing forward on this @NullVoxPopuli!

[NullVoxPopuli]

Closing this RFC, in favor of separate RFCs (linked from the PR description)