Difference between Ember.get() and this.get() - ember.js

I'm new to Ember and it keeps confusing me about the difference between this.get() and Ember.get(). Can someone explain them briefly?

Welcome to Ember ;-)
Every object that extends Ember Observable mixin supports the get() method (among others).
When you call this.get(), the this must refer to such an object (Route, Controller, Component, your own class that extends Ember.Object and so on). Calling get() on plain object would cause a failure. Let me show the difference:
const emberObjectInstance = Ember.Object.create({
name: 'Bala'
});
emberObjectInstance.get('name'); // returns 'Bala'
const plainObject = { name: 'Bala'};
plainObject.get('name'); // causes a failure since get() is not a function
However, using Ember.get() successes in both cases:
Ember.get(emberObjectInstance, 'name'); // returns 'Bala'
Ember.get(plainObject, 'name'); // returns 'Bala', too
which can be also written with imports as follows
import { get } from '#ember/object';
get(emberObjectInstance, 'name'); // returns 'Bala'
get(plainObject, 'name'); // returns 'Bala', too
Note: not to forget, calling either of get() makes computed property get computed (in the most common cases, I don't want to dive deep now - lazy computation, volatile extensions etc), but for the sake of understanding the difference, we can work with plain values.
From own experience, I am using Ember.get() everywhere I know a plain object might be the object whose property I need to retrieve. A nice example is setupController() hook into which I may pass plain object from my unit tests to test setupController()'s functionality.
// some route:
setupController(controller, model){
this._super(...arguments);
const name = Ember.get(model, 'name'); // ***
controller.set('isNamePresentOnSetup', Ember.isPresent(name));
}
// in my unit tests I can use plain object:
...
const modelMock = { name: 'Bala' }; // plain object is enough because I use Ember.get instead of model.get() (see ***)?
const controllerMock = Ember.Object.create(); // has to be Ember.Object since I use controller.set() within setupController()
subject.setupController(controllerMock, modelMock);
assert.ok(controllerMock.get('isNamePresentOnSetup'), "property 'isNamePresentOnSetup' set up correctly if model name is present");
...
I could also user Ember.set(controller, 'isNamePresentOnSetup', Ember.isPresent(name)) and then pass plain controller mock into setupController(), too.
I think this is a good start since you are new in Ember and I am sure Ember gurus would have much more to add.
Relevant Ember docs:
https://guides.emberjs.com/v2.9.0/object-model/
https://guides.emberjs.com/v2.9.0/object-model/computed-properties/
https://guides.emberjs.com/v2.9.0/object-model/reopening-classes-and-instances/
UPDATE:
Using get() with chained paths works different than working with POJOs.
For example in objectInstance.get('a.b.c') if b is undefined the return value is undefined. Converting this to objectInstance.a.b.c when b is undefined would instead raise an exception.

There is none. foo.get('bar') is equivalent to Ember.get(foo, 'bar'). However because foo.get is defined on Ember.Object you can only call .get() on Ember Objects. Ember.get() will work on all ember objects. On Ember Objects Ember.get(foo, 'bar') is equivalent to foo.get('bar'), on every other object its equivalent to foo['bar'].

Please note that using Ember.get() or this.get() is not needed anymore for most use cases if running Ember >= 3.1, which was released in April 2018. You could now use native ES5 getters. A quick introduction to this change could be found in release notes for Ember 3.1. It's discussed more in detail in RFC 281.
There is a codemode available that helps you transition to ES5 getters: es5-getter-ember-codemod It could be run as part of ember-cli-update.
Please not that using Ember.get() or this.get() is not deprecated. It's still needed for some edge cases, that are listed in release notes linked above:
In fact there are several cases where you must still use get:
If you are calling get with a chained path. For example in this.get('a.b.c') if b is undefined the return value is undefined. Converting this to this.a.b.c when b is undefined would instead raise an exception.
If your object is using unknownProperty you must continue to use get. Using an ES5 getter on an object with unknownProperty will cause an assertion failure in development.
Ember Data returns promise proxy objects when you read an async relationship and from other API. Ember proxy objects, including promise proxies, still require that you call get to read values.
Please note that there is a special case if using ember-changeset. It provides it's own .get() implementation. Therefore Ember.get(this, 'value') and this.get('value') have different results if this is an ember-changeset. You find more information on that case in documentation of ember-changeset.

Related

Sinon stub instance method declared in mapDispatchToProps

New to testing and React Redux, so I may be conflating a few issues here. I will only present one example, but I have tried many different combinations of mount(), shallow(), instance(), stub, spy and more.
Given a component, where setFooData() updates redux state and Foo.props.data:
const mapDispatchToProps = (dispatch, props) => ({
setFooData(fooId, data) {
dispatch(Actions.setFooData(fooId, data));
},
});
...
return (
<div fooId={this.props.fooId}>
<Foo {...fooProps}/>
</div>
);
I would like to write some tests around the conditions under which setFooData() is called, namely conditions in lifecycle methods like componentDidMount() and componentWillReceiveProps().
Because setFooData() involves server calls and more, and because these tests merely concern the view layer and how the component renders as a result of Foo.props.data being set eventually by setFooData(), setFooData() seems like a good candidate for stub.
Therefore, Enzyme's shallow(), rather than mount(), seems appropriate, correct? In any case, when I try to stub setFooData():
let wrapper = return shallow(<Foo {...props}/>);
let stub = sinon.stub(wrapper.instance(), 'setFooData');
I receive the error:
Attempted to wrap undefined property setFooData as function
Upon inspection, wrapper.instance() yields an object where setFooData() is indeed not defined, but according to other examples, I would think it should be.
Furthermore, setFooData() does exist on wrapper.instance().selector.props, and while let stub = sinon.stub(wrapper.instance().selector.props, 'setFooData'); avoids the error, when I inspect the object setFooData() =/= stub, and the function is not called as per the test.
When I use mount() instead,
let wrapper = mount(<Provider store={store}><Foo {...props}/></Provider>);
let componentDidMountSpy = sinon.spy(Foo.prototype, 'componentDidMount');
let componentWillReceivePropsSpy = sinon.spy(Foo.prototype, 'componentWillReceiveProps');
expect(componentDidMountSpy.called).to.be.true; //passes
expect(componentWillReceivePropsSpy.called).to.be.true; //passes
expect(stub.called).to.be.true; //fails
I receive a different error that appears related to the body of setFooData(), so setFooData() is called but the function is not actually stubbed to prevent its real body from being executed.
Thanks for any help to clarify my understanding.
I think you're taking the hardest path. You should test your component in isolation, not the connected one. If you test the connected component you're making an integration test and double testing that connect indeed works. That's already tested in react-redux for you.
Instead, test your action creators by themselves in unit tests.
Then, export your component as named export without connecting and use the default export for the connect version.
That way you can simply import the pure-React version and pass anything you want as props, in order to make easy assertions afterwards.
If you need to specifically test that something happens in those lifecycle methods, you can call those methods from the instance:
const fakeActionCreator = sinon.spy()
const subject = mount(<MyComponent doSomething={ fakeActionCreator } />)
subject.instance().componentDidMount()
assert.equal(fakeActionCreator.callCount, 1)

How do I get the BeforeObserver equivalent in Ember 2.3?

To preface this, I must clarify that I am using the legacy-controller and the legacy-view for the interim period while transitioning to Ember 2.3, found here:
https://github.com/emberjs/ember-legacy-controllers
Now, I have a property called currentTopPost on my (legacy) controller.
In Ember 1.7, I had this setup:
// before observer
currentTopPostBeforeObserver: function(){
...
}.observesBefore('currentTopPost'),
// observer
currentTopPostBeforeObserver: function(){
...
}.observes('currentTopPost'),
The reason I had it this way was that when the currentTopPost changed, I wanted it save the old topPost before it switched its value to the new property, as it was a Post object (I had a Post model).
Of course, in 1.7, I saved the old post in the beforeObserver and then did whatever else I had to do in the observer. Now, In Ember 2.3, I have this set up:
currentTopPostObserver: Ember.observer('currentTopPost', function(){
...
}),
Which works fine as far as performing functions with the new value goes. But I've lost the ability to process an action before the value changes. Now according to an answer to this question:
How can an observer find out the before and after values of the observed property in Ember.js?
the observesBefore function has been deprecated and we should be following this:
doSomething: Ember.observer( 'foo', function() {
var foo = this.get('foo');
var oldFoo = this.get('_oldFoo');
if (foo === oldFoo) { return; }
// Do stuff here
this.set('_oldFoo', foo);
})
However, on trying to use this.get("_oldCurrentTopPost"), I get nothing. How do I access the old value of this property before it changes ?
What I use as a replacement is:
propWillChange(prop) {
//your new before observer
},
propDidChange: Ember.observer('prop', function() {
let prop = this.get('prop');
if (this._oldProp !== prop) {
this.propWillChange(this._oldProp);
this._oldProp = prop;
}
//Do stuff
})
Of course, on the first run, _oldProp will be undefined, but that's expected, right? It is the first time prop is being changed.
I also disagree that observers shouldn't be used. I agree that observers should be avoided if possible, because many people don't fully grasp their side-effects, but in many cases they are very useful, especially when building 3rd party plugin integrations.
Since the question specifically asks about a beforeObserver replacement, here it is. However, I recommend to reconsider if your use case can be rebuilt without observers if possible.
Twiddle: https://ember-twiddle.com/045b7b9c1562ceb6bbdc
As far as I can tell, there is no particularly nice way to get that mechanism back. Observers themselves are "considered harmful" in many cases, but I'll try my best to give you a practical alternative solution.
The best quick and relatively dirty way to do this that I can think of is to make a "proxy" computed property with a getter and setter. Within the setter you can get the previous value of the "real" property, call out to a function to do whatever, and then set the new value on the real property.
Here's an example that you could use:
myProxyProperty: Ember.computed('myRealProperty', {
get() {
return this.get('myRealProperty');
},
set(key, value) {
const oldValue = this.get('myRealProperty');
this.doSomethingWithOldValue(oldValue);
this.set('myRealProperty', oldValue);
}
})
Unfortunately I don't know of a better way of doing this in new Ember at the moment.

ember computed alias breaks when getting first or last object

The goal was to have a computed property based on whether there was an existing object in the store or not... Based on this answer, I believe that it should be okay to get the first object (or last) in the context of a computed alias. So here is what I'm trying to do:
import Ember from 'ember';
export default Ember.Controller.extend({
sessions: function () {
return this.store.peekAll('session');
}.property(),
// this doesn't work...
currentSession: Ember.computed.alias('sessions.firstObject'),
// this seems to work...
lastSession: function () {
return this.get('sessions.lastObject');
}.property('sessions.lastObject'),
...
});
I'm using ember 1.13.8 and didn't know if this might be related to an existing ember issue or if it's a bug or just me trying to use ember in a way that it wasn't meant to...
Just to clarify, it would appear that once the alias is computed, that 'getter' becomes undefined for the sessions array. So after that point, (in the above example) calling this.get('sessions.firstObject') would return undefined, as would calling this.get('sessions').firstObject
Is this a bug? If not, what's happening behind the scenes here?
Thanks!
This does work actually... I think it is likely something to do with the manner of testing in which I was setting properties on the window so that I could inspect them in the console. Maybe some other code was interfering, I have no clue, but it's working now.

Adding custom functions to Ember.js ArrayControllers

I'm trying to figure out Ember.js and keep hitting what seems like basic problems that are not documented in a way I understand.
I want a object to manage a list of stuff. ArrayController seems to make sense. I assume having that controller load the data from the 3rd party server (youtube) makes the most sense. So My plan is to write some custom functions in the controller to load the data.
App.videoController = Ember.ArrayController.extend({
loadSomeVideos() {
console.log("I have run");
}
});
after I run the above code App.testController.someFunction() does not exist. Why not? I feel like I am missing some basic concept.
When you call Ember.ArrayController.extend, you're actually just extending the class not creating a concrete instance, therefore you can't call loadSomeVideos.
There are a few conventions in Ember that can get you stumped if you're unaware of them. As commented by "Unspecified", you should use the following convention to extend the class.
Please note the upper case VideoController and also the way in which I'm defining the loadSomeVideos method:
App.VideoController = Ember.ArrayController.extend({
loadSomeVideos: function() {
console.log("I have run");
}
});
Now, if you want to run this, you need to create an instance of the App.VideoController class. Once again notice the capitalisation:
App.videoController = App.VideoController.create();
So, I use a lower case v for the instance, and an upper case V for the class. I've just created an instance (App.videoController) of the class (App.VideoController).
To call your method, you need to call it from the instance, like this:
App.videController.loadSomeVideos();
Check out the following two pages in the documentation.
This first page gives you some info about extending classes and then instantiating them so you can call their methods:
http://emberjs.com/guides/object-model/classes-and-instances/
The second page goes into a bit of depth about more advanced methods reopen and reopenClass.
http://emberjs.com/guides/object-model/reopening-classes-and-instances/

ember computed properties executed when

I have inherited a codebase written in Ember 0.9.8.1
In some cases it can be very slow.
I'm in the process of narrowing down why it is slow.
I have noticed the following.
A function in an ArrayController is called to load data.
To load the data it gets json from the backend (fast) and then for every row it creates an (previously defined) Ember.Object (slow) and push that to the content[] of the ArrayController.
Example:
App.ExOb = Ember.Object.extend({
data1: null,
data2: null,
func1: function () { // statements }.property('data1').cacheable()
func2: function () { // statements }.property('data2').cacheable()
..etc..
})
App.lotsOfData = Ember.ArrayController.create({
content: [],
loaddata: function() {
var self=this;
get_data().forEach(function (row, index) {
var d = App.ExOb.create(row.data);
self.pushObject(d);
}
}
})
I'm trying to figure out why the creation and push of the Ember.Object is slow.
What I did notice was that on creation of the object (in the example App.ExOb.create()) every property function of the object (in the example func1() and func2()) is called.
I've tried a small bit of ember code to see why this would happen but can't seem to emulate this. The only time I can see the computed property being executed is when I do a get() of that property.
Can anyone tell me (or point me to documentation that I missed) when a computed property function is executed (other than doing a get() ofcourse :-) )?
Edit:
So far I found the following reasons to execute a computed property:
1. Calling/using the property directly
2. Using the propery in a handlebars template that is shown in the browser.
This is just a quick stab at the problem, but have you tried to create the ExOb and initialize its properties manually, something like:
self.pushObject(App.ExOb.create({
data1: row.data.data1,
data2: row.data.data2,
... etc ...
});
That might be faster, as Ember doesn't have to guess at what to copy from the row.data object and into the App.ExOb object.
Generally, the func1() and func2() functions wouldn't need to be overloaded upon object creation in my mind, but your requirements might dictate otherwise.