A common requirement for building logging plugins is pulling context from the environment, for attaching along with the log.
An example is a Koa request, a sample of which could look like this...
ctx = { request:
{ secure: true,
headers: { 'content-type': 'text/plain' },
href: 'http://google.com/?q=whatever' },
response: { status: 200 },
length: 40,
message: null
}We could do with a generic pluck util in @timberio/tools which lets us request a 'path' of deeply nested object keys, and returns just those keys in a new object - which we can then attach along with the request.
For example, given the `ctx above...
keys = ["length", "request.headers", "response.status"]
pluck(keys, ctx)
... we'd get back this:
// `request.href` and `message` are omitted
{ request: { secure: true, headers: { 'content-type': 'text/plain' } },
length: 40,
response: { status: 200 } }There are utils that already get close to this - object-path, Rambd's path, etc - but all the tools I've seen return only single values.
Instead, we want the full, original object path, returned as a new object.
It'd also be nice to avoid using a large library like lodash / Ram(b)da, and have our own minimal function.
@aks- -- this is a good one for you.
A common requirement for building logging plugins is pulling context from the environment, for attaching along with the log.
An example is a Koa request, a sample of which could look like this...
We could do with a generic
pluckutil in@timberio/toolswhich lets us request a 'path' of deeply nested object keys, and returns just those keys in a new object - which we can then attach along with the request.For example, given the `ctx above...
... we'd get back this:
There are utils that already get close to this - object-path, Rambd's path, etc - but all the tools I've seen return only single values.
Instead, we want the full, original object path, returned as a new object.
It'd also be nice to avoid using a large library like lodash / Ram(b)da, and have our own minimal function.
@aks- -- this is a good one for you.