(handler) => {
return async (request) => {
const userExists = await calltoDB(request.user)
if (!userExists) // return "you have to login!" immediately to client
return handler(request)
}
}
@hnry
response() does the same thing as the bottom example, except response() also gives you helper functions
a valid response (not the function) is just saying
{ status: 123, headers: { ... }, body: "..." } you get it? but people might find writing it the manual way tedious so that's why i included functions for creating it like response()
I was just wanting to clarify how the return response() vs return handler(req) is managed internally with the compose promise reducer
@hnry
you are calling them when you say handler(req)
it simply calls the outer function:
(handler) => { // <---- spirit calls this function
return async (request) => { // <-- this is the result of handler(request) / the previous middleware
const userExists = await calltoDB(request.user)
if (!userExists) return response("you have to login!")
return handler(request)
}
}
so if you return early like in the example, it doesn't call the next middleware/handler, and so it just unwinds early
bc the reducer is calling all the function no matter if they return a value (eventually transformed into a promise) or handler(req)
oh
if not that's ok, i have an idea of what you mean and can look into it still
are you sure your condition is working ok?
everything must be fine then, sorry...
thank you
versus instead of running once only
As for production ready, yea I believe so, but the parts that I haven't tested thoroughly is proxy forwarding and there's no built in etag generation (but can always add your own)
@hnry @dodekeract in a vanilla node server response there is a
sendDate property which you can set to false to disable this header. Don't recall how to access the vanilla response with spirit though, @hnry?
And the main middlewares like body parser and cookie session support I re-used express versions is because of time. I've tried reaching out to some of the authors to see if they can just provide the lib or some lean version of their lib without the express parts and usually that doesn't go anywhere.
Which is cool, but yea I think the body parser can be faster than the express one, but just time and priorities of what to focus on
export default handler => request => {
return new Promise((resolve, reject) => {
const req = request.req();
const chunks = [];
req.on('data', data => {
chunks.push(data.toString());
});
req.on('end', () => {
request.body = chunks.join('');
console.log(request.body);
resolve(request);
});
});
};
Technically there's a performance hit in general when using middlewares in spirit just like in express, but in different areas