Argument Default Primitives

[pzuraq]

Rendered

[snewcomer]

Do Glimmer components and their component managers support positional params?

[pzuraq]

Glimmer components do not support positional parameters, which is why the proposed setDefaultArgs API for Glimmer components only accepts named arg defaults. In general though, the VM does not really distinguish between components with and without positional parameters. You can invoke a Glimmer component with positional parameters, like so:

{{my-glimmer-component @positional1}}

And the VM will pass that positional parameter to the component - there is just no way for the component to use that positional argument or refer to it in any way, since the underlying manager does not expose it. That's why in general, manager APIs receive both named and positional args.

[jelhan]

What are the benefits to treat null the same as undefined? It seems to limit the component APIs significantly.

[pzuraq]

The main idea was just keeping it consistent between the way null and undefined are handled when interpolating in templates, so the rules are consistent in templates. I agree this could be limiting though, and in JS for instance, ?? is different than argument defaulting. ?? will coalesce if the value is null or undefined, whereas argument defaulting will use the default value only if it is undefined.

Are there motivating use cases you can think of for when users would want to be able to pass null, and not trigger a default? It would be helpful if we could show such use cases in the motivation

[ro0gr]

Not a specific use case, but I believe these are just semantically different. I may want to tell to a component, the value must be initialized with nothing.

[jelhan]

I find it difficult to come up with a realistic use case. I can image many components, which support null as a value for one of their arguments. So please excuse if that example may sound a little bit made up.

Let's imagine a <Switch> component, which three states: true, false or null. The component may be used in a poll to select the answers a) yes, b) no, c) I don't know.

The component has a @value argument, which allows a consumer to pass in the state. For unknown reasons the developer of the component decides that the argument is optional and that true is a good default for it.

If the argument default primitives do not distinguish between null and undefined, this use case would not be supported. The default value would be used even if the consumer explicitly invokes the component with @value={{null}}.

[mehulkar]

We use null to opt out of using a default component name. This could probably be better modeled with named blocks though.

[wagenet]

It's unclear that we still need this, especially with template imports. If I'm mistaken, please let me know and I'll reopen and work on getting this reviewed.