7

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;
    }
}
Fedoranimus
  • 816
  • 6
  • 20
  • Maybe this could be helpful https://stackoverflow.com/questions/28419242/property-change-subscription-with-aurelia – Daniel Bejan Aug 12 '17 at 23:51
  • 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. – Fedoranimus Aug 12 '17 at 23:54
  • I think you should set `state.activeSession` instead of replacing the object with `this.state = response`. – jmvtrinidad Aug 14 '17 at 02:42
  • 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. – Ashley Grant Aug 14 '17 at 21:21
  • Right, that's what I'm seeing @AshleyGrant and what I have observed elsewhere with `@observable` and `@computedFrom`. This is disappointing. – Fedoranimus Aug 14 '17 at 21:24
  • 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. – Ashley Grant Aug 14 '17 at 21:28
  • 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. ;-) – Fedoranimus Aug 14 '17 at 21:31
  • 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. – Ashley Grant Aug 14 '17 at 21:34
  • It's `state` that changes, not `state.activeSession`, basically. – Ashley Grant Aug 14 '17 at 21:34
  • I think this is an important question. And I think I'm going to write a blog post about it. Thanks for the idea! – Ashley Grant Aug 14 '17 at 21:40
  • Ha, happy to help! – Fedoranimus Aug 14 '17 at 21:40

2 Answers2

5

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.

Balázs
  • 2,929
  • 2
  • 19
  • 34
2

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;
        }
    )
}
Fedoranimus
  • 816
  • 6
  • 20
  • 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. – Ashley Grant Aug 14 '17 at 21:29
  • Thanks, that makes sense. This is less code, but feels less clean to me. It's just my sensibilities, I suppose. – Fedoranimus Aug 14 '17 at 21:32