by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    hnry
    @hnry
    @DylanPiercey thank you for sharing though for sure
    i am going to take a break afk for a bit
    Rick Medina
    @rickmed
    yeah, rill and spirit can surely learn much from each other, both are awesome projects
    Dylan Piercey
    @DylanPiercey
    Anyways if you are looking for an Isomorphic way to do a bunch of random things check out the rill modules, if you get stuck making something work definitely shoot me a message as I love solving these types of problems.
    Rick Medina
    @rickmed
    @DylanPiercey what are your thoughts on this.body vs return body?
    EG: if you see from the koa example the first downstream middleware needs to check if this.body is present. The whole thing is an anti-pattern IMHO. Edit: can be done better.
    Dylan Piercey
    @DylanPiercey
    I think this should be avoided in any framework, rill passes the context as the first argument to functions. However I think ctx.res.body = is nice and explicit, returning something doesn't really say "I set the response body".
    Rick Medina
    @rickmed
    i disagree. Returning something means "hey, I'm returning the thing that you asked for". Using OOP for using the word "body" is not nearly worth it imo
    Dylan Piercey
    @DylanPiercey
    But with http servers (at least in nodejs) are built in an OO way. You don't just return a response body, you have to return statuses, headers, body, and much more in an http request. I think that returning the body is a cool idea that could be made to work, but I think its a bit of a dangerous abstraction.
    Rick Medina
    @rickmed
    why dangerous?
    fwiw, that is what spirit does
    Dylan Piercey
    @DylanPiercey
    Yeah I know thats what it does. I think it's dangerous because with the web, like I said, there is more than just a response. What about http2 (push)? Sockets? Events? How do you represent those as responses?
    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