fn & on

[NullVoxPopuli]

related info: https://www.pzuraq.com/ember-octane-update-action/

[mixonic]

@NullVoxPopuli @bound is merely a proposal afaik, I'm not even sure if it is even a concrete proposal to TC39. I think the guides should stay focused on how to get thing done, and avoid contributing to FUD about what the future will bring.

[NullVoxPopuli]

Gotchya.

yeah, after reading the propoal for decorators closer, it looks like bound would be something ember may provide, given this implementation example from the decorators proposal:

export decorator @bound {
  @initialize((instance, name) => instance[name] = instance[name].bind(instance))
}

These are the only decorators being proposed as part of the proposal:

[mixonic]

I know some work supporting async/await landed into backburner and Ember in 3.x, but I'm not sure if FW core is encouraging this in app code yet. I've queried a few people for clarification.

Regardless, I'm not sure why this action is async... Simply to provide an example that it is possible?

[NullVoxPopuli]

I've been using async/await everywhere in emberclear, and haven't ran into issues. 🤷‍♂️

I think the the name implies that there is going to be some interaction with a backend, so I would expect it to be async :)

[mixonic]

This Note is pretty confusing. As a reader I'm not sure what this comment (something something focus) has to do with actions on non-clickable elements.

This is likely trying to nudge the user to think about accessibility? Can it be structured so that a first time using coming to this section can get the information they expected before that consideration distracts them?

[NullVoxPopuli]

This Note is pretty confusing.

yeah, I struggled with it a bit, too.

This is likely trying to nudge the user to think about accessibility?

I think so. I've primarily only used Chrome and FireFox, so I haven't run in to any issues with browsers not letting things be clickable. I wonder if this text is counting a screen reader or other a11y tool as a browser.

[NullVoxPopuli]

Not sure what to do about these notes -- kinda out of scope for this Pr, but if someone else wants to tackle it / open an issue for it, be my guest!

[CvX]

Could/should the docs provide a migration guidance for the value="target.value" pattern?

For example, given this code:

<input onclick={{action "update" value="target.checked"}} type="checkbox">
<input oninput={{action "update" value="target.value"}}>

actions: {
  update(value) {
    console.log(value);
  }
}

Is this the recommended replacement?

<input {{on "click" this.update}} type="checkbox">
<input {{on "input" this.update}}>

@action
update({ target: { checked, value } }) {
  console.log(checked || value);
}

And is there a path for (mut) and value combo? 🙂 For example:

<input oninput={{action (mut this.query) value="target.value"}}>

You'd have to create an action in the component that updates this.query, right?

AFAICT, the {{on}} RFC didn't touch on that? @pzuraq

[pzuraq]

@CvX I believe the first few examples should be the preferred form. Currently, we don't have a path to a direct replacement for mut/value, I agree this is a bit regrettable but we did explore this significantly during the design portion of the on and fn RFCs. The issue is that the current API is very counterintuitive:

• mut does nothing directly on its own, it returns a function that sets a value. You still have to apply that function. This means that you have to know how the details of the surrounding environment work, which takes us to action and value
• value is a really weird API, basically allowing you to reach into an event and grab a nested path to pass to the next thing. You need to know that the path will be followed on the event object itself, which is something that people trip up over frequently. It also does nothing valuable by itself - why wouldn't you just want the event in an event handler? It only makes sense in the context of the mut helper.

Basically, these APIs are convenient in that they are terse, but they are not easy to teach, and do not have much utility unless they are used together. We realized through the design process that what we really want here is some form of closures:

<input {{on "input" (|event| (set this.query event.target.value))}} />

Something along these lines. However, this is a huge lift, and adds a large amount of complexity to both Glimmer from an implementation perspective and templates from a language design persective, so I'm not sure if this is a direction we want to go yet.

I think in the meantime, it would be best to make a custom helper that handles common use cases like this, where it would be inconvenient to create an action handler. call it pickAndSet:

<input {{on "input" (pickAndSet this "query" "target.value")}} />

This would pick the value off of whatever is passed to it and set it. Then at least the two actions are related to each other lexically, and can tell the users that they are related just by reading it. You could use a template transform to mimic the mut helper if that would be clearer:

<input {{on "input" (pickAndSet this.query "target.value")}} />

[muziejus]

Thanks @NullVoxPopuli and @locks for talking this through with me. I think this hits the key terms (binds, class) while also, with the second sentence, explaining in a more quotidian way why @action is needed!

[muziejus]

that comma before "and" is not needed and causes confusion.

[muziejus]

While at it, this should have a period at the end to follow the style of the rest of this list.

[jenweber]

Thank you @NullVoxPopuli and reviewers! If anyone wants to extend upon this work or make additional fixes, I'm happy to help get more PRs merged in!