An ability to specify default values for @named arguments

[lolmaus]

Previously, I was able to provide default values to arguments like this:

component.js:

Component.extend({
  foo: 'bar'
})

template.hbs:

{{foo}}

result:

bar

It was a simple, efficient and very declarative way of specifying default values. It both worked well and was obvious to developers reading the code.

---

With named args, this no longer works. Though an argument passed externally does overwrite this.foo, setting an initial value to this.foo does not affect @foo in the template.

As a result, there is no way of specifying a default values for arguments!

The only workaround I'm aware of is to keep using {{foo}} or {{this.foo}} instead of {{@foo}}. This works, but it defeats the purpose of @-named args in templates.

---

Thus, we need a simple, declarative way of specifying default values for arguments used in components.

A developer should be able to tell which arguments are gonna have which default values by simply looking at the component JS file. Those definitions should not be obscured inside a hook such as init.

[lolmaus]

To be clear, I do NOT want to be using {{@foo}} for arguments without default values and {{this.foo}} for arguments with default values. Such approach creates a lot of confusion.

I want a way to provide default values for named args and keep using them as {{@foo}}, otherwise the named args RFC makes no sense to me.

This is true both for Classic and Glimmer components.

[NullVoxPopuli]

Update (2021-05-23) (and after having spent a lot more time with Octane, and teaching it to folks)

I no longer think the opposite of @rwjblue
I am more... 🤷

To be clear, I do NOT want to be using {{@foo}} for arguments without default values and {{this.foo}} for arguments with default values. Such approach creates a lot of confusion.

fwiw, I think the opposite.

we know that {{@foo}} comes from the caller.
we know that {{this.foo}} is a properties in the current context/component.

(just for clarity, and thoroughness), at present, the only way to get the same behavior as in classic components is via:

get foo() {
  return this.args.foo || 'some default value';
}

and since args are readonly, we can't modify them -- we can't do any sort of dynamic default value setting (like what is possible in classic components).

The only option I really see for still using {{@foo}} and having a default value, is if we set static default values.

export default class MyComponent extends Component {
  static defaultArgs = {
    foo: 'some default value'
  };
}

however, this introduces an extra layer of complexity, and the merge of args with defaultArgs happens behind the scenes, and may just add 'one more thing' to a beginners set of things to learn / have to deal with.

my preference for a default value pattern would be something like this:

export default class MyComponent extends Component {
  @defaultArg('foo', () => 'the default value') foo;
}

and then still accessed via {{this.foo}}, because it's then a thing defined on the component.

However, this still uses a string to reference an arg, which I don't like, so the getter is my go-to for now.
(I avoid strings / any dynamic code via strings at all costs)

[chriskrycho]

One thing to consider for a design around this is that one of the points of arguments is that they're immutable; so you'd want an approach—whether using decorators or something else—that lets that guarantee still be upheld for the idea of defaults.

Personally, I strongly prefer the explicitness of using a getter and saying "This is my own derived state," however it is derived. That makes it clear in the template that when I see @foo I'm looking at something that was passed in without any kind of transformation or alteration. A thing that can be passed optionally or can be given a different value has different semantics.

That said, optional arguments with defaults in JS are a thing, so I'm not opposed to coming up with a comparable solution here; I just want it to be the case that we don't lose the other benefits of named args.

[lolmaus]

@NullVoxPopuli: my preference for a default value pattern would be something like this:
and then still accessed via {{this.foo}}

@chriskrycho: I strongly prefer the explicitness of using a getter and saying "This is my own derived state," however it is derived.

I do not want to access some of my arguments via {{@foo}} and others via {{this.foo}}. It's hard to remember which is which. When you have a dozen of arguments, it's a huge pain.

Also, default values for arguments are a very common use case. It's not some caprice that developers, be they quirky enough to desire it, should figure out on their own.

The worst is that when providing a default value with a getter but not passing any value from the parent template, {{@foo}} and {{this.foo}} will have different values. And if I confuse one for another, I'll have unexpected results, with the code looking completely legit and leaving me clueless.

I don't want this gotcha to be scattered all over my code like rakes (gif inside).

---

@NullVoxPopuli:

export default class MyComponent extends Component {
  @defaultArg('foo', () => 'the default value') foo;
}

How is this ☝️ better than these 👇 ?

export default class MyComponent extends Component {
  foo = 'a default value';

  get bar() {
    return this.attrs.bar || 'another default value';
  }
}

Either way you still need to revert to {{this.foo}} in templates, which defeats the purpose of @-named args.

---

@chriskrycho: That makes it clear in the template that when I see @foo I'm looking at something that was passed in without any kind of transformation or alteration. A thing that can be passed optionally or can be given a different value has different semantics.

But arguments passed externally do get written into the this context of the component! That's the only thing I can be 100% certain about.

And I want to avoid mistakes and confusion, my only option is to always use {{this.foo}}. It will work predictably and will never cause any issues.

But I don't want to be a black sheep. And I do want to see a distinction between arguments and properties in my templates. It's just arguments with default values are still arguments! They've always been.

[lolmaus]

Note that there's no linter (and can hardly imagine one to exist) for warning you that you're using {{@foo}} whereas a default value is available.

[NullVoxPopuli]

When you have a dozen of arguments, it's a huge pain.

I think maybe we have something else to talk about now <3

Can you give an example of something where'd you have this many args?

. It's hard to remember which is which

fwiw, the point is not to remember, but to be able to discover. Apps are too big to keep in your head, ya know?

How is this point_up better than these point_down ?

imo, the getter is better, because there is no string access on args.

my only option is to always use {{this.foo}}.

that defeats the purpose of read-only args. ya don't always need a default. :-\

[lolmaus]

Oh wow, doing get foo() {} and passing @foo from a parent template crashes Ember! 🤦‍♂️

[lolmaus]

that defeats the purpose of read-only args.

That's what I said in the top post, and this is exactly the reason to request an RFC for default values.

[NullVoxPopuli]

Oh wow, doing get foo() {} and passing @foo from a parent template crashes Ember! man_facepalming

that's probably because we have to support classic accessing for those not fully on the named args train.

once we get rid of classic arg accessing, that won't be an issue

[lolmaus]

@chriskrycho: Personally, I strongly prefer the explicitness of using a getter and saying "This is my own derived state," however it is derived. That makes it clear in the template that when I see @foo I'm looking at something that was passed in without any kind of transformation or alteration. A thing that can be passed optionally or can be given a different value has different semantics.

I can agree with that for Glimmer components. They are more strict and are a new entity, so a shift of a mental model is acceptable.

But everyone's mental model for Classic components is that an argument can be accessed in a template the same way, regardless of whether it has a default value or not. Adding (or removing, for that matter!) a default value to/from an existing argument did not force me to update my template. It just worked, and that's how it should be.

The named arguments RFC changed that. 😒 But note how adding a default value now requires rewriting a template from {{@foo}} to {{this.foo}}, but removing a default value does not require switching back to {{@foo}}.

It is an inconsistency and a source of confusion. I've been always subconsciously uncomfortable using @ & this in Classic component templates and now I understand why.

[Panman82]

This was discussed elsewhere (apparently not on the RFC) and I seem to recall the answer (for the time being) was to be {{or @argName "static value"}} or {{or @argName this.argDefault}}. The only issue with that is what if the @argName is falsy and that's what you'd want. Maybe we need a {{default}} helper to only pass the second/default value when the arg is undefined. Related: #388

[NullVoxPopuli]

It is an inconsistency and a source of confusion.

you could still use classic / ambiguous access: {{foo}}

where,

import { Component } from '@ember/component';

export default class MyComponent extends Component.extend({
  foo: 'default value',
}) {
 // class body
}

[lolmaus]

@Panman8201:

{{or @argName "static value"}}

There are two huge issues with this approach:

1. It's a pretty universal convention to have default values defined near the top of the component's JS class.
2. What if the value is used multiple times in a template? You'll have to provide the default value multiple times. It's tedious and prone to regressions.

[lolmaus]

@NullVoxPopuli: you could still use classic / ambiguous access: {{foo}}

Which equally defeats the purpose of named arguments RFC.

BTW, you don't need to use .extend() for that. Class property works.

[Panman82]

@lolmaus
There are two huge issues with this approach:

1. It's a pretty universal convention to have default values defined near the top of the component's JS class.
2. What if the value is used multiple times in a template? You'll have to provide the default value multiple times. It's tedious and prone to regressions.

1. Putting defaults on the component JavaScript class won't be a viable solution for "template only" components. So the solution for this issue has to be in the template.
2. That's why I put {{or @argName this.argDefault}} as another example as a way to show the option of putting the default value in one place to reference. Another template-only solution would be to {{let "some default" as |argDefault|}} and then {{or @argName argDefault}}.