Aurelia's computedFrom with an object

Question

I have a state object which has a property session, this property can either be an object or null.

I don't want to have to dirty-check for the isSessionActive() getter, so I'd like to use computedFrom(). However, computerFrom() doesn't seem to fire when this object changes, unless it was undefined previously.

Can I do this without a dedicated isSessionActive boolean property on my state Store?

@autoinject
export class Home {
    firstName: string = "user";
    private state: State;

    constructor(private store: Store) {
       store.state.subscribe(
            response => this.state = response
       )
    }

    @computedFrom('state.activeSession')
    get isSessionActive() {
        return this.state.activeSession !== null;
    }
}

Sacramentalism

Maybe this could be helpful #28419742 – Andrel

I've already subscribed to my store's state. I could trivially fire a callback event and update the getter manually, but it wasn't as clean. – Sacramentalism

I think you should set state.activeSession instead of replacing the object with this.state = response. – Drainpipe

What you have should work, but it's only going to call the getter if state.activeSession changes, not if state.activeSession.foo changes. It only is going to notice when the entire object gets swapped out, not when a property on the object changes. – Hhour

Right, that's what I'm seeing @AshleyGrant and what I have observed elsewhere with @observable and @computedFrom. This is disappointing. – Sacramentalism

It's not disappointing, it's doing exactly what you told it to do. You told it to watch for changes to state.activeSession. From the looks of your code, it'd be better to tell it to watch for changes to state, since this.state gets swapped out completely whenever that subscription callback is fired. – Hhour

You're right. However, I keep finding that I want to observe any mutations on a specific property inside an object. I shouldn't necessarily be observing mutations though. ;-) – Sacramentalism

I take back my original statement that the code as written should work. As I look at the code, I realize the reason it is failing is that when you swap out the state object, Aurelia loses the observer on the state.activeSession property as it is observing a property on the previous object that was assigned to this.state. Thus Aurelia never notices the state.activeSession property changing because it doesn't change. – Hhour

It's state that changes, not state.activeSession, basically. – Hhour

I think this is an important question. And I think I'm going to write a blog post about it. Thanks for the idea! – Hhour

Ha, happy to help! – Sacramentalism

Answer 1

I ended up just doing the following:

isSessionActive: boolean = false;

constructor(private store: Store) {
    store.state.subscribe(
        response => { 
            this.state = response;
            this.isSessionActive = response.activeSession !== null;
        }
    )
}

Sacramentalism

See my answer above, I would probably end up accomplishing this the way you have in this answer, as it is less code, but you could do it with @computedFrom('state)` on the getter. – Hhour

Thanks, that makes sense. This is less code, but feels less clean to me. It's just my sensibilities, I suppose. – Sacramentalism

Answer 2

I can see that you have already solved your problem but it is rather a workaround than an actual solution. Therefore I'd like to come up with some explanation as to why you experience this and how to solve it. Basically, your question is pretty much a different case of the same problem described here.

I've provided a detailed explanation in the comment section as there was a guess-answer, so I'm going to repeat myself here.

---

The important bits of code are these:

private state: State;

// ...

@computedFrom('state.activeSession')

Like I already explained here, the way Aurelia change detection works is that when Aurelia gets involved in observing some value, it sets up custom getters and setters in place of the respective field or property. Basically, what the setter does is it calls the original property setter (or sets the original backing field) and then notifies any interested parties (i.e., whatever binds to that property) that the value has changed.

Never mind if that does not make sense to you, all that matters is that whenever you bind to something, that something has to be in place before the binding is set up. Like explained in the comment section of the linked answer, if you write this:

private state: State;

this is just a hint to TypeScript that state is semantically correct on the defining class. In other words, since you don't set it to anything, it is left out of the transpiled JavaScript code altogether - all it does is it makes the usage of state valid in TypeScript.

For example, if you did this:

class A {
  x: number;
}

then the resulting JavaScript would be something like:

function A() {
}

Notice that there is no this.x! However, if you wrote this instead:

class B {
  x: number = undefined; // or null, or whatever you like
}

then the resulting JavaScript would be:

function B() {
  this.x = undefined;
}

The difference between the two is that in the first case, there is no property to bind to. Because of that, Aurelia has no way of subscribing to it because it has no way of knowing when (in JavaScript) that property starts to exist on the object. It is important to note here that, if you inspected the value in the console like so:

var a = new A();
var b = new B();
console.log(a.x); // undefined
console.log(b.x); // undefined

Both a.x and b.x seem to be undefined. But they are different: a.x is undefined because it does not exists on a, while b.x is undefined because it is explicitly assigned a value of undefined - so it does exist, it just happens to have a value of undefined. The latter scenario does enable Aurelia to set up its custom logic on the properties while the former does not.

In summary, to make your computed property work, all you need to do is assign a default value (eg. undefined, null) to all the properties which are involved in its computation. It is a good practice anyway.

Nonscheduled

Thanks, that offers a lot of context. – Sacramentalism