amark on master
thanks @rogowski book test read… Merge branch 'master' of http:/… (compare)
amark on master
Allow Dockerfile to auto-update… (compare)
amark on master
rad fixed dup text, perf, read … (compare)
.put({}, function (_data, _key, msg) {...})
and use msg
instead of _data
inside callback for that matter 🤔? But that would still keep the data on the nodes
webrtc.js
. I am at the same place as before root.on('out',
just does not fire an event when I try to use it. but in original webrtc.js
code it is definetly used for messaging
Briefly, I am doing something like this
side One
gun.get('+'+opt.pid).on(function(last, key, msg){
if(opt.rtc.start > msg.put['>']){ return }
root.on('out', {'@': ''+msg['#'], '#': root.ask(open), ok: {rtc: {id: opt.pid}}});
});
side Two
gun.get('+'+ack.ok.rtc.id).put(opt.pid, open); // put stuff in the same node and expect respone in callback
but side Two never gets my ACK
gun.get('+'+opt.pid)
and gun.get('+'+ack.ok.rtc.id)
are the same node
useCallback
gets called multiple times by React, which inside you then .on(
which creates new subscription listeners each time - therefore accumulating more & more listeners over time.root.ask(function(ack){})
builds a TCP/HTTP-like req/res ontop of GUN's otherwise UDP-like messaging system. It doesn't do anything itself, it just returns an ID that it associates with your callback, message IDs on wire are like var msg = {'#': root.ask(cb), ...}
which you root.on('out', msg)
(be careful: you might need to in
it versus out
, it depends!) then another machine just has to ACK that msg ID, so you var reply = {'#': 'asdf', '@': msg['#'], ...}
that gets sent out or in. You could keep chaining these, where the reply itself may want a reply so you do instead: var reply = {'#': root.ask(cb), '@': msg['#'], ...}
and so on...Gun.state.is(data_node, keyName)
1 of the few internal utilities I kept :P
gun.user().get('timegraph').time(foo)
)?