Is an observable prop, but not observable?

[hitsthings]

class TEST  {}
class TEST2 extends TEST {
    notes = []

    get privateNotes() {
        return this.notes.filter(() => true)
    }

    init() {
        makeObservable(this, { privateNotes: computed, notes: observable })
    }
}

const test = new TEST2()
test.init()
console.log('test', {
    isObservableProp: isObservableProp(test, 'privateNotes'),
    isComputed: isComputed(test.privateNotes),
    isObservable: isObservable(test.privateNotes)
})

This outputs test {isObservableProp: true, isComputed: false, isObservable: false, isObservableArray: false}. I'm struggling with how this is possible. Shouldn't the observable be deep by default? Shouldn't the computed prop be observable as well?

Thanks for any help!

[hitsthings]

Ok so calling .filter() or .slice() or other methods seem to not return observables by design.

I would have expected that if the set of privateNotes changed (for example you added a private note to notes or deleted a private note from notes), an observer accessing something like privateNotes.length should react.

Thinking through why the design is the way it is. I guess creating a new array from the old one usually wouldn't be reused, so making it observable doesn't make sense. It would be cool if there were some kind of gate when using computed though, where the value is turned observable with continuity with previous values returned from the function. But perhaps mutating the previously returned array is too spooky?

I might be answering my own question here...

[mweststrate]

You need to mark 'notes' as observable as well.... isComputed also needs a property name as second argument here. (Or use isComputedProp, don't know from memory, see the api docs)

…

On Thu, 17 Nov 2022, 06:07 Adam Ahmed, ***@***.***> wrote: Ok so calling .filter() or .slice() or other methods seem to not return observables by design. I would have expected that if the set of privateNotes changed (for example you added a private note to notes or deleted a private note from notes), an observer accessing something like privateNotes.length should react. Thinking through why the design is the way it is. I guess creating a new array from the old one usually wouldn't be reused, so making it observable doesn't make sense. It would be cool if there were some kind of gate when using computed though, where the value is turned observable with continuity with previous values returned from the function. But perhaps mutating the previously returned array is too spooky? I might be answering my own question here... — Reply to this email directly, view it on GitHub <#3579 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBGHPLMES3VOZ3VTPI3WIW4SJANCNFSM6AAAAAASC5VQRI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[hitsthings]

Yeah I forgot the annotation for notes in the first version, but had edited it in - didn't affect the results. isComputedProp` is what I actually wanted, thanks!

I think my misunderstanding is rooted in the fact that observableArray::filter does not return an observable array - just a regular array. I will have to keep that in mind in the future. Thanks for being part of my learning process here. :)