Object.prototype got lost.

[WolfSoko]

When I try to save an $resource object into store e.g.

$resource('/user/:id').get({id :123}).get().then(function(user){
    flux.dispatch('saveUser', {user : user});
});

then inside my store we have the correct $resource object. When calling getUser() from store, the copy of the AppStore.user is no $resource anymore it becomes an object.

How far can we go with deepcopy in such a situation? Is it possible to return the object without losing it's prototype?

[christianalfoni]

Hi there,

This is a very good point indeed. Ideally a store only stores normal values. Like you would only store the user object, not the wrapped $resource. The only way to access a prototype on an instance is through the proto property, but that is not something you would want to do. So bringing a long the prototype on cloning is a problem.

But let us discuss this a bit. Let me start with a question. Do you need to save the $resource in your store? If I stated that you can only store plain objects, arrays and primitives in a store. Do you see that as immediate problem?

[WolfSoko]

The advantage of storing the (resolved) $resource object is, that the (custom) methods for further work with the $resource are still available.

E.g. user.$logout() or user.$activate() or user.$children() in my specific case.

Also the object type information is very important when it comes to some decisions. I think or hope methods are not a big problem for immutability because they describe behavior and not data. Also in OO languages like Java a (deep-)copy of an object has still the same class and therefore the same behavior.

[christianalfoni]

What we could do is check the object constructor. If the constructor is not the plain Object constructor

On Thursday, February 5, 2015, Wolfram Sokollek notifications@github.com wrote:

The advantage of storing the (resolved) $resource object is, that the (custom) methods for further work with the $resource are still available.

E.g. user.$logout() or user.$activate() or user.$children() in my specific case.

Also the object type information is very important when it comes to some decisions. I think or hope methods are not a big problem for immutability because they describe behavior and not data. Also in OO languages like Java a (deep-)copy of an object has still the same class and therefore the same behavior.

— Reply to this email directly or view it on GitHub https://github.com/christianalfoni/flux-angular/issues/23#issuecomment-73065496 .

[christianalfoni]

Damn mobile... What I was saying:

What we could do is check the object constructor. If the constructor is not the plain Object constructor we can grab the constructors prototype and create the new object with that. This requires that the object has the constructor on its prototype though. But Angular has that, as it is best practice. That will solve the problem.

On Thursday, February 5, 2015, Wolfram Sokollek notifications@github.com wrote:

The advantage of storing the (resolved) $resource object is, that the (custom) methods for further work with the $resource are still available.

E.g. user.$logout() or user.$activate() or user.$children() in my specific case.

Also the object type information is very important when it comes to some decisions. I think or hope methods are not a big problem for immutability because they describe behavior and not data. Also in OO languages like Java a (deep-)copy of an object has still the same class and therefore the same behavior.

— Reply to this email directly or view it on GitHub https://github.com/christianalfoni/flux-angular/issues/23#issuecomment-73065496 .

[christianalfoni]

Okay, added fix for this now, will release bug fix soon

[WolfSoko]

Awesome it works. Thanks a lot.