operation field in graph edge/cycle events

[joprice]

I'm working on a realtime visualization of the zedux graph that currently uses the flat snapshot. I'd like to update it in realtime based on ecosystem events, but I'm unsure if I can recover the same information from those events to rebuild the graph in another process incrementally. Specifically, I'm trying to get the operation that an edge event relates to, but I found that operation is not present in edge or cycle events. I thought of getting it from the edge events source.o field, but that is an array, so I'm not sure which to attribute the event to. I see EventBase has operation as an optional field. Should it be defined for these events, or is there a deterministic way to recover it from the graph using the data in the event?

[bowheart]

Ah, you probably don't want to use viewGraph for a custom graph builder. It's meant to be a high-level API for seeing some basic info about your graph. At least I think that's what you're referring to with observers being an array. source.o shouldn't ever be an array on any event.

This task requires using some of Zedux's obfuscated APIs. A low-level helper would be nice for this. Tagging #143 again.

I was writing up an example here of how to do a manual snapshot with cycle and edge events updating it, but it's pretty involved. So I decided to go and make a full sandbox for it. I used stackblitz this time, it seems better right now.

https://stackblitz.com/edit/vitejs-vite-dwy1ktj1?file=src%2FApp.tsx

[joprice]

Thank you! Yes, I was mixing things up with the array comment in my logs. Disregard that.

I think this is enough for me to get my prototype working, but I'm trying to make sure I understand the events in case I'll be sending too much or too little data over the wire. I'm syncing this data over a websocket to a tauri app, and want to have the graph structure, the current atom value, and the atom template config (ttl, tags, etc). My thought was the edge event only updates edges, cycle updates the node state, and change updates the node's value, but that leaves me wondering what determines node creation, as in what order do cycle, edge and change events come in.

Is the purpose of snapshotting to in cycle in your example mostly for a new node, since others would have their edges updated by the edge event? For instance, if a node goes stale then active again, that implies that something is newly observing it, which I assume would send an edge event, making the snapshotting in cycle redundant. But is there anything else that could have changed where snapshotting in that case is useful? I don't want to fall out of sync by missing updates.