app开发者平台在数字化时代的重要性与发展趋势解析
636
2022-11-04
JS小型中间件堆栈库
Small middleware stack library. Analogous to co but without relying on fancy language features. Weighs ~0.4kb gzipped.
Usage
var nanostack = require('nanostack')var stack = nanostack()stack.push(function timeElapsed (ctx, next) { var start = Date.now() next(null, function (err, ctx, next) { if (err) return next(err) var now = Date.now() var elapsed = start - now console.log('time elapsed: ' + elapsed + 'ms') next() })})var ctx = {}stack.walk(ctx, function (err, data, next) { if (err) throw err})
How does this work?
A stack is a "last-in, first-out" type structure. The last thing that's added is also the first thing that's taken off when you "unwind the stack".
In nanostack we push middleware onto the stack. This means that middleware is first executed upwards (e.g. next function in sequence) until next() is called without a callback. When that happens the stack starts to unwind, and middleware is executed downwards. You can think of the execution order like this:
Nanostack1. 7. Middleware 1==============2. 6. Middleware 2==============3. 5. Middleware 3============== 4. Middleware 4
Sequence: middleware 1, middleware 2, middleware 3 middleware 4, middleware 3, middleware 2 middleware 1
A keyd thing to note here is that any part of middleware can cause the stack to unwind. This is done by not passing a callback into the next() function. This is for example useful to handle create generic error handlers for the whole stack of middleware.
API
stack = nanostack
Create a new nanostack instance.
stack.push(cb(ctx, next))
Push a new handler onto the middleware stack.
stack.walk(ctx, next)
Call the functions on the middleware stack. Takes an initial context object and a callback.
next([err], [value], [handler])
Call the next function in the stack. If handler is not passed (e.g. last argument is not a function) the stack unwinds, calling all previous handler functions in reverse order (e.g. as a stack).
FAQ
Why did you write this?
I realized that most frontend and backend plugin systems / middleware is often best expressed as a stack that can execute some code at the start, handing off control to a function up the stack and then execute some more code when it regains control (before handing control off again down the stack).
co figured this out a while ago, but relying on newer language features prevented it from being generally applicable (for me). This package takes the same ideas and allows them to run in more environments.
When shouldn't I use this?
This package is probably best left for frameworks to consume / when doing more complex-ish architecture things. Generally the last handler on the stack would be a message bus / router that enables multiple handlers to resolve. If you're building something simple that might be all you need actually. Or if you want to get fancy you might want to consider using a package that consumes this one and exposes a neato pattern on top.
Similar Packages
tj/co
License
MIT
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~