-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include metadata that can be emitted along with events #81
Comments
The only thing I have even approaching the level of an opinion is that This brings us to the nature of the symbol. If it's > x = Symbol.for('test')
Symbol(test)
> y = Symbol.for('test')
Symbol(test)
> x === y
true I don't know if this is more an argument for |
Two things to note: - The key is the string `'META'` - The value is `Symbol('proc-log.meta')` So it could be used like the following. All of the following is up to producers/consumers to implement with shared conventions. All `proc-log` is doing to allowing them to share a unique `Symbol`. ```js const { output, META } = require('../') // An example of how consumers would see if a META object // was the last argument from an event const getMeta = (args) => { let meta = {} const last = args.at(-1) if (last && typeof last === 'object' && Object.hasOwn(last, META)) { meta = args.pop() } return [meta, ...args] } process.on('output', (level, ...rawArgs) => { const [{ force = false }, ...args] = getMeta(rawArgs) console.log(level, { force, args }) }) // in this implementation the value does not matter, just the key output.standard('arg1', 'arg2', { [META]: null, force: true }) output.standard('arg1', 'arg2') output.standard('arg1', null) output.standard(null) output.standard() // Will log the following: // standard { force: true, args: [ 'arg1', 'arg2' ] } // standard { force: false, args: [ 'arg1', 'arg2' ] } // standard { force: false, args: [ 'arg1', null ] } // standard { force: false, args: [ null ] } // standard { force: false, args: [] } ``` Closes: #81
proc-log
is designed to be Just an Event Emitter ™️ with some well known event names.This means it passes along all arguments when emitting to consumers. This is a good approach because there are rarely changes that
proc-log
needs to make outside of adding new methods. If a producer sends arguments then it is the consumers responsibility to consume them somehow.Our primary use case is displaying things in a terminal. So all arguments are passed to
util.format
which can take anything as input. We might be displaying a string, number, plain function or custom class with a[util.inspect.custom]
method.BUT most of the examples I wrote out in npm/statusboard#810 rely on some kind of well-known metadata to be useful. This is why I think
proc-log
should have some way to indicate "this event contains an argument that is special and belongs to proc-log. It will have data in it that you should look at differently than the rest"Possible Solutions
Producers
proc-log
itself should have some sort of ergonomic API to send this metadata.meta() function on each method
top level meta() function
use a symbol to set a key
Consumers
Consumers listening with
process.on(eventName)
should have some ergonomic way to know that an argument is metadata.level argument is metadata too
helper to find metadata in args
The text was updated successfully, but these errors were encountered: