by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Dylan Piercey
    @DylanPiercey
    Not saying I am right though, it could probably be made to work - I just can't envision it easily.
    Express/Koa/Hapi esq styles are somewhat tried and true, even in other languages.
    Rick Medina
    @rickmed
    websockets is a separate thing, you return the resource however you want and THEN establish the connection
    Dylan Piercey
    @DylanPiercey
    I'd have to see it, after all this is only my initial thoughts. The framework is certainly interesting, I look forward to giving it a whirl when I get some time. (Currently about to board a plane).
    Rick Medina
    @rickmed
    http2 is just as http response.end (response.push) without the client requesting it
    (websockets) that is how it is done with express/koa
    also, spirit design was inspired by ring (clojure), since there wasn't an implementation like it in js, simply bc the js community don't embrace fp as much as they could
    Dylan Piercey
    @DylanPiercey
    Ah ic. I thought when you were saying return you were going to just return in some function, if you have to call .push, .end or otherwise then it's not that different.
    Not bad though.
    Alright, i've got to go, chat with you all later!
    @DylanPiercey laters
    Rick Medina
    @rickmed
    @hnry question: how do I return a response to the client from the upstream (the function with the req param)?
    do I need to go through the whole middleware chain any how?
    hnry
    @hnry
    @rickmed this is without spirit-router?
    @rickmed you would use response(), or file_response(), err_response(), redirect(), from spirit.node
    important to know that a response is just a small hash { status, headers, body } so you can return { status: 123, headers: {}, body: "Hello" } which is the manual way of making a response
    all the response() and file_response() functions i mentioned are just helpers to help make that small hash
    Rick Medina
    @rickmed
    I don't follow... What I mean is something like:
    
    (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()
    Rick Medina
    @rickmed
    yes yes, I'm super clear about the response_map and the helper functions...
    I was just wanting to clarify how the return response() vs return handler(req) is managed internally with the compose promise reducer
    @hnry
    hnry
    @hnry
    oh the reducer (spirit.compose) doesn't actually call your functions
    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
    Rick Medina
    @rickmed
    I did a test, as I suspected, the response is done correctly but the middleware chain is still ran all the way
    bc the reducer is calling all the function no matter if they return a value (eventually transformed into a promise) or handler(req)
    hnry
    @hnry
    that's a bug then, i'll have to take a look, do you have a small example i can see?
    oh
    if not that's ok, i have an idea of what you mean and can look into it still
    Rick Medina
    @rickmed
    just have an early mw return respond() and do some side effect with a later mw like log and you'll see
    hnry
    @hnry
    ok
    hnry
    @hnry
    i can't reproduce
    are you sure your condition is working ok?
    Rick Medina
    @rickmed
    super weird, I deleted the first test and then tried to recreate it unsuccessfully -scratching my head...
    everything must be fine then, sorry...
    hnry
    @hnry
    @rickmed no worries, it's helpful still to double check for my own sake ha
    thank you
    hnry
    @hnry
    @rickmed by the way, i think i see what you were saying, found an issue closely related to what we were talking about...
    Right now there's an issue where:
    (handler) => {
       // code here always runs (but it shouldn't)
        return (request) => {
        }
    }
    versus instead of running once only
    Rick Medina
    @rickmed
    maybe that's how I found the issue back then...
    hnry
    @hnry
    i think so :)
    Florian Wendelborn
    @dodekeract
    Do you think this module can be called "production ready"?
    Florian Wendelborn
    @dodekeract
    Oh, also - is it possible to remove the Date header?