Closed cblgh closed 3 years ago
cc @nikolaiwarner @khubo @substack any thoughts on the above? let me know where things are unclear and i'll write comments + docs to clarify 🖤
basically: client commands now emit:
channels
, names
, whisper
etc)/channels
command that has a header info message and then emits all channels in subsequent messagesend
event, signifying the end of info stream/clear
would only be updated if some other type of event (e.g. peer connection) was triggered after a clear had been issued—bug probably surfaced by this commit)i encapsulated the extra data in the meta
key of the emitted object, primarily to prevent future collisions if we add / tweak emitted event data. let me know if i should collapse the contents of meta
back to the original object
so
> /channels
[...]
this.cabal.on("info", msg => {
const meta = msg.meta
// meta consists of: meta.uid, meta.command, meta.seq
console.log(meta)
// => { uid: '1613387148891', command: 'channels', seq: 23 }
})
This PR makes all slash commands'
info
event also include which command triggered the event. As a consequence, handling command output in react-style apps like cabal-desktop should be a lot easier and less haphazard.CabalDetails._res
has been converted from being an object, returning three functions (info
,error
,end
), to a function. The function takes the command type as an argument, and calling it returns the same object as previously—the key difference being that the three functions have had their payload annotated to include the command type.(n.b. This is not entirely correct, as only
info
has been annotated to include thecommand
key,)The emitted
command
event has also been removed, as it was unused in most places I can see cabal-client being used (I checked desktop, cli & timgoeller's bot framework).@nikolaiwarner @khubo lmk if this doesn't make sense (i think it should tho?)