Ember.js - Ember 3.11 Released

Blog
1

Today the Ember project is releasing version 3.11 of Ember.js, Ember Data, and Ember CLI. This release kicks off the 3.12 beta cycle for all sub-projects. We encourage our community (especially addon authors) to help test these beta builds and report any bugs before they are published as a final release in six weeks' time. The ember-try addon is a great way to continuously test your projects against the latest Ember releases.

This is a companion discussion topic for the original entry at https://emberjs.com/blog/2019/07/15/ember-3-11-released.html
1 Like
2

Awesome work to everyone involved!

I have a question about {{fn}}. It wasn’t clear to me from this part of the post

{{!-- when not passing arguments, these are equivalent --}}
<MyButton @click={{this.countUp}}>Add One</MyButton>
<MyButton @click={{fn this.countUp}}>Add One</MyButton>

whether or not the @action decorator was still needed on the class’s method after we introduced fn:

class CounterComponent extends Component {
  count = 0;

  @action
  countUp(increment = 1) {
    this.incrementProperty("count", increment);
  }
}

I clicked through to the RFC and saw this example:

image
image1428×478 20 KB

which led me to think that fn also binds the this context? If so, do we need the @action decorator at all, if we always us {{fn}}? If not, I find this snippet from the RFC a little confusing since call in JS binds context to the first arg.

3

Looks like fn does not bind this, per https://github.com/emberjs/ember.js/blob/0de75b8f751ae13b14b08f0ee6dd7958737fff34/packages/%40ember/-internals/glimmer/lib/helpers/fn.ts#L72

Looks like the native js ‘call’ is used: https://github.com/emberjs/ember.js/blob/0de75b8f751ae13b14b08f0ee6dd7958737fff34/packages/%40ember/-internals/glimmer/lib/helpers/fn.ts#L103

Not sure where that context var comes from. On phone atm.

Edit: line 9 has context. Untouchable this. Lol

4

Hey guys, we use Ember since version 1 and we are really excited with all the evolution we see in the Framework. Thank you very much!

The splattributes feature is amazing! That raised to me an old issue that I have when writing components. It would be nice to be able to forward all the params received by a component, just like splattributes does for HTML attributes. For instance, if I instantiate a component like:

<MyComponent @param1="val1" @param2="val2" />

It would be nice to be able to (inside MyComponent’s hbs);

<MyWrappedComponent ...params />

There are many cases that I see this as a bad thing to do, but in some cases, wrapper components specially, that’s just what we need.

Is it possible already? Is there any RFC that intends to implement that?

1 Like
5

@acras I’ve read in this article that “splarguments” are being discussed. Unsure of current status.

1 Like