Named arguments don't work with default values?



Ember 3.1 introduced named arguments in components and I wanted to give it a try in a component I wrote. The component implements a musician form and is therefore called musician-form :slight_smile: It has the following API:

// new.hbs

As is often the case, the form is used both on a new and an edit page. In the latter case, when it’s used to update an already existing musician, the selectedBands is not passed in as I want the bands related to the musician to be pre-selected:

// edit.hbs
{{musician-form musician=model bands=bands on-submit=saveMusician}}

Let’s actually see how it is used in the component’s template:

{{!-- app/templates/components/musician-form.hbs --}}
  onchange=(action (mut selectedBands)) as |band|}}

The component initializes the selectedBands if it’s not passed in by the caller, to the bands the musician already belongs to:

// app/components/musician-form.js
export default Component.extend({
  async init() {
    if (!this.selectedBands) {
      let bands = await this.musician.get('bands');
      this.set('selectedBands', bands.toArray());

That works wonderfully.

Let’s switch to named arguments:

{{!-- app/templates/components/musician-form.hbs --}}
  onchange=(action (mut selectedBands)) as |band|}}

The first case, passing in selectedBands on the new page still works, but when selectedBands is not passed in, the component breaks – no band is pre-selected for the dropdown, even though the init method still runs the this.set('selectedBands', bands.toArray()) line just fine. So it seems like setting an attribute in the component’s code when it’s not passed in doesn’t make it available as a named argument, so setting it to a default value is not possible. (Note that selected=this.selectedBands works!)

The other thing to note is that (mut @selectedBands) is not possible either, an error is thrown (Assertion Failed: You can only pass a path to mut).

Do you know of a way to make setting default values to arguments work with named arguments? I find it’s a really useful pattern and would love to have it work with this new feature. Thank you.


I had this discussion with @rwjblue and it seems like this is the intended behavior. One reason is because with @myArg you know that comes directly from outside of the component, so any defaults kind of mess with that.

The suggested ways to do default values are using something like

  • Use init hook and set a new value (e.g. myUpdatedArg) using the passed in and the default value
  • Use getters (IMO should be used more in Ember code)
  • {{or @myArg 'default'}}

With the second option, you get the benefit of using {{this.myUpdatedArg}} which you know might have been changed in the component.js.

I think there is some room for the addon ecosystem to do something about better DX. I think is positioned really well for this (or maybe ember-decorators).


Thank you for your swift reply. Being able to see at a glance what comes from outside the component indeed has some benefit, I’ll admit.

To set a default value, what kind of getters do you mean?


Something like

get myUpdatedArg() {
  return defaultTo(this.myArg, 'defaultValue');

Using in the example above.

Although not sure if there are any caveats/differences between Ember.Object and ES Classes when using this method. cc @pzuraq


I wrote up a bit about this in this issue thread:


A couple more thoughts/questions as I work with named arguments:

  1. As we’re still passing in arguments the same way from the caller (for example, {{musician-form maxBands=3 (...)}}), there’s no way to prevent component code from mutating the passed in value, even though the use of the @ sigil in the component’s template should warn against this. I can do this.maxBands += 1 in the component’s init and then {{@maxBands}} in the template will render 4, not the passed in value.

I don’t think Ember can prevent this, but it might be something we want to teach people about (and as I’m writing the advanced level sequel of the R&R book, I should do that, if I’m right).

  1. I have a hard time seeing why using named arguments in the template doesn’t work in some contexts. I’ve found these ones not to work:
  • (mut @selectedBands) – prints “Assertion Failed: You can only pass a path to mut”
  • {{v-get @musician 'name' 'message'}} – Doesn’t log anything but the validation error message is simply not rendered (works with passing musician to v-get). v-get comes from the ember-cp-validations add-on, which makes me wonder whether add-on authors need to do something so that their components/helpers also work when named arguments are passed into them.

Having to use both the @ and the plain form in the same template could be confusing and I also didn’t know where I can safely use the @ form before trying.


Could you please provide a reproduction? As far as I understand named arguments that should be considered a bug. Here is an ember-twiddle showing how it should work:


I must have done something wrong because you’re right, {{@maxBands}} still refers to the original value so the @ creates an immutable reference.

That might also explain why mut throws an error as @selectedBands is a read-only reference and mut by definition updates the passed-in reference.

It might also explain why {{v-get @musician 'name' 'message'}} doesn’t work. The passed in @musician refers to the original version of the object that’s passed in and when the underlying musician object is updated (when ember-cp-validations sets a validation error on it), the {{v-get}} doesn’t re-render because it’s passed an immutable reference that never changes.

In this way, {{@musician}} is the same as {{unbound musician}}, isn’t it?


An unbound binding does not update after the initial rendering, which is not what happens with named arguments. {{@musician}} is more like as if the argument was passed to the component as read-only: {{musician-model musician=(read-only model)}}.


You’re right that’s an important difference, thank you for pointing it out.


Just want to point out that you can switch the calling side too:

<MusicianForm @maxBands=3 />

This is polyfilled all the way back to Ember 2.12 and implemented natively in 3.4.


Looks great, thank you (I didn’t even know 3.3, and thus 3.4-beta was out), I’ll play around with switching the call to angle-bracket component.