Hierarchical logging of computeds

[IanBellomy]

I have a complex network of derivations that runs great (thanks MobX!) but I'd like to log value changes with respect to the upstream values that caused the change, i.e. hierarchically / as a tree.

Example:

Before using Mobx, the computed functions were 'update' functions. I could construct an isomorphic log by relying on the call stack and pushing and popping contexts. (In most cases it was safe to assume that if an update was running there was a difference to log but in many cases a previous value was cached to compare against.)

e.g.

updateA(){
    pushLog("A") // creates "A" log node.
    if ... updateX()
    else ... updateB();
    popLog()
}
updateB(){
    pushLog("B") // creates "B" log node.
    updateC()
    if ...  updateX()
    popLog(); // Remove the B log node, assuming everything else is pushing and popping as it should. 
}

updateC(){
   pushLog("C")
   //...
   popLog();
}

updateX(){
   pushLog("X")
   //...
   popLog();
}

With computeds and reactions though there is no clean call stack, so I'm not sure how to properly construct an isomorphic log tree.

I can create reactions for each computed but they will of course run at the end and without a guaranteed order and sans any kind of info on the chain-of-causation so to say.

It smells like I might be able to assemble the log tree after the fact if I kept track of the computed's debug names and then do some kind of dependency lookup in a reaction before appending the log entry — see if a previous entry in the log is a dependency, and if so, append the new log entry to that previous entry. But the log itself is an observable and updating it after the transaction will create other complications — ideally the transaction that triggers the computed would contain the changes to the log.

Are there any features in mobx that'd make this problem just go away or otherwise simplify it?

[mweststrate]

Did you check the `spy` API?

…

On Fri, Jul 15, 2022 at 11:35 PM Ian Bellomy ***@***.***> wrote: I have a complex network of derivations that runs great (thanks MobX!) but I'd like to log value changes with respect to the upstream values that caused the change, i.e. hierarchically / as a tree. Example: [image: CcZwT] <https://user-images.githubusercontent.com/17239616/179318805-1d99cd30-3844-4f9d-8402-d43591242e03.png> Are there any features in mobx that'd make this problem just go away or otherwise simplify it? (Note: In the diagram the change to A could cause X to change but did not.) (In the event that a computed would have been triggered by multiple changes, it'd be ideal to treat it has having been caused by the first item touched in the graph.) I can create reactions for each computed but they will of course run at the end and without a guaranteed order and sans any kind of info on the chain-of-causation so to say. It smells like I might be able to *assemble* the log tree after the fact if I kept track of the computed's debug names and then do some kind of dependency lookup in a reaction before appending the log entry — see if a previous entry in the log is a dependency, and if so, append the new log entry to that previous entry. But that sounds brittle... — Reply to this email directly, view it on GitHub <#3467>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBEHAPM6JE4JDUBX7F3VUHRTFANCNFSM53XAIDBA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[IanBellomy]

I guess you would clear all the logs at the start of every action?

Bingo. Er... wait, are you talking about the return value of computed or the general 'log' I'm trying to build.

I think you need some notion of a "turn" (a single derivation step), for which you get that log tree - I think that would map to a single batch in mobx (?)

Bingo. MobX's transactions map well to player actions.

The idea was that you set a new log together with the new value, so the unchanged dependencies would have an empty log.

Not sure I follow. In your example I'd assume that dep1.log anddep2.log would either be a new value or a mobx-cached value such that log: [[dep1.log, dep2.log], ... would always have two pieces of data no matter what, making it impossible to know which (if not both) had changed... 🤔

Keep in mind that computeds are lazy

Apologies, I'm taking for granted that these computeds are consumed by observer react components.

Otherwise you would need some additional heuristics like you want the first one that invalidated computed.

Bingo.

Both of the deps can be changed in a single action, therefore both could be an equally good reason for it to run, therefore both of their logs are relevant.

If I'm mistaken and it is the case in your example that only a changed dep will produce a log value, than yes I follow that it makes sense to say log: [[dep1.log, dep2.log]..., but it seems to me they will both always have values, making it impossible to distinguish between cases where only dep1 was responsible for a change or vice versa.

[urugator]

It's not like I think it through completely, just throwing ideas around...

computed(() => {
  return {
    value: dep1.value + dep2.value
    log: dep1.log.length === 0 && dep.log.length === 0
      ? []
      : [[dep1.log, dep2.log], 'This computed entry'],
  }
}, { equals: comparator.struct }) // the log is also relevant

doSomethingAction() {
  // clear logs for all values, also invalidating all the computeds
  this.a = { value: this.a.value, logs: [] };
  this.b = { value: this.b.value, logs: [] };
  this.c = { value: this.c.value, logs: [] };
  // do something
  this.a = { value: "new", logs: ["new value set"] }
}

[IanBellomy]

Ah, I think I follow. It's an interesting idea I think and one that could solve the need [edit: maybe not] 🤔...

Maybe because MobX provides getDependencyTree(observable, prop) and it provides the root cause in other places, I was hoping for a way to keep computeds focused on the values they need to provide and access the metadata about the overall procedures separately.

Maybe it's just an aesthetic thing on this end / feels a little sad to have to invalidate everything and also a little weird to mix values with metadata that's of a kind available through other Mobx mechanisms 🤔...

Really appreciate your thoughts though!

[IanBellomy]

(It may also feel smelly to me because I previously basically got the needed information for free using a call stack of update functions but now there's hoops for the simple things so that the hard things could be simple 🤔.)

[IanBellomy]

Looking closer I'm not sure how invalidation works.  🤔
• It is not possible to overwrite computed values
• Modifying a .log property of a returned computed value won't have any effect on Mobx's cached values, and these internal cached values will be used next the computed is re-run, meaning the log value of the dependency will just be whatever it was / never empty.

[IanBellomy]

Question clarification and working (albeit sloppy) solution

Desired use case:

// Within some action...

// set a property on an observable
observable.prop = 1

// get a tree/graph where 'prop' is the root and the specified computedProps, if changed, are the deepest nodes.
const results = causalTreeFor( 
   [observable, 'computedProp'],
   [observable, 'computedProp2'],
   [observable, 'computedProp3']
) 

// place the results where needed

I have a working solution but it's kinda of sloppy and involves looking at parts of computed Atoms that aren't public.

/**
* Taking for granted that only one observable property changed, we should be able to trace a path back to that single prop.
* If there are alternate routes, it's ok we end up with one.
* I'm almost certain that the observing_ array order corresponds to the order of use in the computed, which is a nice bonus — it should mean the priority for items that dirty the computed (if multiple) ends up being their use in the computed. 
*/
function causalChain(atom:ComputedValue<any>):ComputedValue<any>[]{
    if(!atom || !atom.dependenciesState_) return [];
    const chain = [atom]
    let proximateCause = atom.observing_.find((a:ComputedValue<any>)=> !!a.dependenciesState_) as ComputedValue<any>
    while(proximateCause){
        chain.push(proximateCause)
        proximateCause = proximateCause.observing_.find((a:ComputedValue<any>)=> !!a.dependenciesState_) as ComputedValue<any>
    }
    return chain.reverse();
}

function causalNodeFromAtom(
    atom:ComputedValue<any>,
    listener:CausalNodeListener = (a,b)=>{return undefined}, // this can be used later to populate the node's description.
    salient?:boolean
){
    const prop = atom.name_.split(".")[1]
    return {
        id:atom.name_,
        atom,
        listener,
        prop,
        //@ts-ignore
        oldValue : atom.value_,
        newValue : undefined,
        //@ts-ignore
        update : ()=> atom.scope_?.[prop], //   :|
        //@ts-ignore
        children : new Set(),
        salient:salient ?? false,
        description: "" as undefined|string
    }
}
function causalTreeFor(...derivedValues:(ReturnType<typeof propListener>|false|undefined)[]){
    const causalNodes = derivedValues.filter(clean).map(o=> {
        return causalNodeFromAtom(
            getAtom(o[0],o[1]) as ComputedValue<any>, // This isn't necessarily true, but non-computed will ultimate be ignored/filtered out later.
            o[2],
            true
        )
    });

    // filter out nodes that we know for sure didn't change
    const dirtyNodes = causalNodes.filter((node)=> !!node.atom.dependenciesState_ );

    const nodes = new Map<string,CausalNode>(
        dirtyNodes.map(node=>[node.id,node])
    )

    const causalChains = dirtyNodes.map(node=>node.atom).map(causalChain)

    const causalChainNodes = causalChains.map(chain=>{
        return chain.map((a:ComputedValue<any>)=>{
            const node = nodes.get(a.name_) ?? causalNodeFromAtom(a)
            nodes.set(a.name_,node);
            return node;
        })
    })

    // update new values
    causalChainNodes.forEach(chain=>{
        chain.forEach(node=>{
            node.newValue = node.update();
            node.description = node.listener(node.oldValue,node.newValue)
        })
    })
    causalChainNodes.forEach(chain=>{
        chain.reduce(
            (previous:CausalNode|null,current)=>{
                previous?.children.add(current)
                return current
            },null)
    })

    const roots = Array.from(new Set(causalChainNodes.map(chain=>chain[0])))

    return roots

}

🤢🙃