refactor so we can use this module in both connect and co (koa) about body

[Raynos]

@jonathanong this used to be both callback & yieldable at the same time.

I removed this recently because i felt it was out of scope and I personally do yield jsonBody.bind(null, req, res) in my code.

the signatures are currentl (req, res, opts, cb) I believe the opts for now is there for { limit: Number } although it could be there for json parsing options.

The reason I use (req, res) is because I have 15 modules like this and remember whether its (req, cb) (res, cb) or (req, res, cb) was really annoying. Also (req, res, opts, cb) is really composable for higher order programming.

I can add a higher order defaults thing.

I'd rather not support middleware because blargh middleware should die.

We should open the qs & strict vs non-strict as seperate issues.

[Raynos]

@jonathanong

There is a bigger conversation here about writing not middleware and not koajs generator middleware and having the web servers community using callbacks & streams for maximum interop. If we all author modules that work cleanly with the http-framework philosophy then we can get more collaboration and less "my express middleware isnt compatible with hapi plugins"

[jonathanong]

yeah, thought about the middleware part again and agree it shouldn't be supported.

[Raynos]

I can also support yieldables with the

if (!callback) return formBody.bind(null, req, res, opts) trick.

[jonathanong]

yieldables aren't a big deal for me. if you add it to docs then i don't mind pointing to this repo in co/koa wiki then. i just don't like bind.

[jonathanong]

as log as you support (req, opts, done) then i don't care :) not sure if you do though. i haven't looked at your code. i'll open issues for the other stuff.

[Raynos]

It's currently (req, res, opts, done).

[Raynos]

v4.2 now supports generators and has documentation for it.

[Raynos]

So I added a bunch of better docs & configuration.

If you need anything else let me know. Not sure how to do the middleware & options stuff. I think connect3 just needs a really thin 10 line bodyParser that does the middleware interface support.

[jonathanong]

hmmm yeah connect isn't a big deal. would prefer if i could do yield body(req, options) though. can i do that? request body parsing shouldn't require res at all.

[Raynos]

I'd rather keep it to (req, res, opts, callback)

The reason I use (req, res) is because I have 15 modules like this and remember whether its (req, cb) (res, cb) or (req, res, cb) was really annoying. Also (req, res, opts, cb) is really composable for higher order programming.

[jonathanong]

no, i don't expect you to change the signature, just make res optional. if you don't want to do you can close this issue. we might just make a wrapper because tj likes stuff like this: cojs/busboy#2

[Raynos]

@jonathanong making both res & options & callback optional is a complex state machine.

[jonathanong]

yes it is, indeed.

[Raynos]

pull request welcome though.

[Raynos]

You can now call it with yield body(this.req, options)

[jonathanong]

sick. i thought it was too complicated to do and overkill, so i was just going to make a wrapper module that does yield body(this, options). if you really love koa, you can doreq = req.req || req so this.req is unnecessary :P.

i'm deprecating the koa-body-parser in favor of this. you should put this in the co wiki!

oooo actually for koa, you can do body(this, options) and check that the first argument has .req and .res instead of figuring out the arguments via type

[Raynos]

@jonathanong the fact that koa has this === { req: req, res: res } is it's own problem.

People that use koa can forever do yield bod(this.req)

[jonathanong]

i guess you don't love koa :( haha

[Raynos]

I added body to the co wiki.

Do you want a pull request on connect3 to use this instead of its own custom stuff ?

[jonathanong]

yeah sure. i was going to do it eventually.

there's this stupid verify feature that someone asked for that you can just remove. i shouldn't have pushed it. we can just point them to this module or raw-body instead.

[Raynos]

I added a pull request to connect3 senchalabs/connect#965

It's not that much cleaner because with a custom querystring & json parser you don't save that much.

[jonathanong]

what's with the async query string parser? is that actually a thing?

and i thought you had a strict option in body.

[Raynos]

@jonathanong there is no strict option.

and the parsers for querystring & json are async to allow for errors in the cb. its not actually async it just uses a cb to avoid having a try catch