Closed benvinegar closed 6 years ago
As long as you are considering a breaking API change, would it be worth considering the way Redux does middleware life-cycle events? http://redux.js.org/docs/advanced/Middleware.html
Just updated with a proposal: "Middleware-inspired approach".
This approach solves a lot of problems, but I'm concerned that requiring developers to invoke next
could make it error prone.
Just edited the proposal to allow users to specify a next
-less callback, in which case we treat the callback as synchronous and just evaluate the return value. This would be similar to how Mocha behaves differently if your test function declares a done
parameter.
Another thought:
Why not just have every callback accept some kind of params
object, instead of declaring individual arguments? That way we can add as many "parameters" as we want, depending on the callback. That means the signatures change to:
Raven.on('success', function (params, next) { ... });
Where params
is an object with contextual parameters. For example, for the data
callback we have:
{
payload: { ... } // outbound data object
error: { ... } // error that created this payload
}
Whereas the success
callback has:
{
payload: { ... } // outbound data object
request: { ... } // request object (if available)
response: { ... } // response object (if available)
}
Looks good to me!
Closing as discuss will be moved to v4 docs. Linked this issue there.
See prior discussion on this in #524
We've begun to stretch the limits of our existing callback system (
dataCallback
,shouldSendCallback
,breadcrumbCallback
). Each of these can be specified duringconfig
, or via correspondingsetX
methods (e.g.setDataCallback
).Example:
Downsides with this system:
error
(the original error object that triggered the callback) (see #483)(data, originalCallback, originalError
), which is burdensome when invokingoriginalCallback
.originalCallback
in order to preserve the callback chaindataCallback
to parse Angular error messages. If the user overrides the callback viasetDataCallback
, they must invokeoriginalCallback
properly or the Angular message parsing is skipped.addX
method for each callback type (adds to code/API bloat)Pros:
There was a previous discussion on this topic in #524, where I proposed an event-based system (similar to
Backbone.Events
orjQuery
) (implementation in #521), but it didn't really have much steam behind it, and felt too different from what we're doing.Goals of a new system
shouldSendCallback
ANDdataCallback
into one – this is already done inbreadcrumbCallback
)ravenSuccess
,ravenError
)Proposal 1: Middleware-inspired
Inspired by Express, Rack, etc:
Taking a cue from Mocha, we could inspect each callback's arity (via
Function.length
) and decide whether it is "async" or not. This means users could drop thenext
param, and do:Pros
Cons
Questions
off
method to remove previously set handlers?Comments welcome.
cc @LewisJEllis @blittle @lbntly @keithhalterman