Koa: Returning new context rather than modifying

[edahlseng]

I'm still fairly new to Koa, and I want to better understand some of its design decisions. In particular, when first learning about Koa, it seemed to me that it could have easily taken a more functional approach. For instance, consider the following example from the README:

app.use(ctx => {
  ctx.body = 'Hello Koa';
});

Instead, the Koa API could have been designed so that this was written to return a new context rather than making modifications:

app.use(ctx => {
  return {...ctx, {body: 'Hello Koa'}};
});

From my perspective, this could add benefits such as making it easier to test middleware (no need to mock functions on the context) as well as playing better with composition chains and functional styles in general. I have a lot to learn about Koa, and I'm curious to know if this has ever been considered. If so, why wasn't it pursued? If not, what are people's opinion of an approach like this?

[fl0w]

I was never involved in the design process of Koa but here's my two cents, for what it's worth. Also, I'm no purist nor expert.

Idealistically, following a pure functional pattern would be nice, though I'm concerned about yet another signature change. From Koa v1 to v2, the middleware signature changed from ([next]) to (ctx, [next]), context was moved from being bound to first argument. I personally with think that to change to the signature again, the benefit seriously needs to outweigh the cost. As for testability, as long as mutation is expected it shouldn't be "harder" compared to a pure functional approach, just different. A thing or two might be said about tooling and/or debugging but I haven't found this to be an issue myself nor do I see issues to support that case.

Koa v1 relied on a ... not a hack maybe, but an elegant abuse of generators which pretty much did then what V8 breaks async-await down to today under the hood. The original goal was to move past the express signature (req, res, next) and bind a combined object as context to each generator middleware. As promises became "all the shiny" the current mutating approach was probably kept to not completely ostracise community middleware. Koa v2 still supports most deprecated Koa v1 middleware through koa-compose koa-convert because of this.

I'm doing allot of guesswork here but hopefully this gives you some insight.

Edit The intention was to reference convert, not compose.

[edahlseng]

@fl0w Thanks for the response! This historical lens provides a lot of valuable insight.

I might try playing around in a fork of koa to see what benefits a more functional approach would provide (won't know until I try!). If there's anything worthwhile that I learn from that, I'll post back here!

[fl0w]

@edahlseng I'm going to close this issue for now. Feel free to continue discussion or reopen the issue. Good luck with your experiment :)