Make “transforms” more flexible by allowing async behavior about json-api HOT 2 CLOSED

Hey Andrew,

At any rate, I think these transforms could detect whether a Promise is being returned, and wait for it to settle if needed.

I 100% agree with this and would welcome a PR.

A related thought that I’ve been thinking for some time is that maybe it would be worth exploring making each of these steps a distinct middleware. Although, that would be a function signature specific to Connect and Express servers, so maybe that doesn’t jive with the project’s vision.

There's definitely a way to do this without binding us to connect's signature, but I'm not sure I understand the value. I guess it would let the user skip the remaining transforms and respond with a success message earlier. Is there a use case for that? (Note: the user can already skip the remaining steps and jump straight to responding by throwing an error in a transform—or, when we implement your suggestion above, by returning a promise that gets rejected.)

from json-api.

I guess it would let the user skip the remaining transforms and respond with a success message earlier.

Yeah, and moreover, it would remove the need for named hooks like beforeSave altogether, because the implementer could insert steps at any position in the chain and decide whether to call next or to send a response. (Either of which can be done in an async callback—only reason it came to mind.) But this is much more hand-waving than is currently necessary to land this feature.

Can you give some guidance on where to add tests for this? Maybe in the create-resource integration tests?

from json-api.