-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Plain Context API (no request/response) #30
Conversation
@martinklepsch looks good, thanks for doing this! About |
Here it is sketched out (untested) #?(:clj
(defn- await-result [ctx]
(if (a/async? ctx)
(recur (a/await ctx))
(if-let [error (:error ctx)]
(throw error)
ctx)))) ; <---
(defn- deliver-result [ctx get-result] ; <---
(if (a/async? ctx)
(a/continue ctx deliver-result)
(let [error (:error ctx)
result (or error (get-result ctx)) ; <---
callback (if error :on-error :on-complete)
f (get ctx callback identity)]
(f result))))
(defn execute-ctx
{:arglists '([interceptors initial-context]
[interceptors initial-context on-complete on-error])}
([interceptors initial-context on-complete on-error]
(execute-ctx interceptors initial-context on-complete on-error identity)) ; <---
([interceptors initial-context on-complete on-error get-result]
(if-let [queue (q/into-queue interceptors)]
(-> (context initial-context queue on-complete on-error)
(enter)
(leave)
(deliver-result get-result)) ; <---
;; It is always necessary to call on-complete or the computation would not
;; keep going.
(on-complete nil))
nil)
#?(:clj
([interceptors initial-context]
(when-let [queue (q/into-queue interceptors)]
(-> (context initial-context queue)
(enter)
(leave)
(await-result))))))
(defn execute
([interceptors request on-complete on-error]
(execute-ctx interceptors {:request request} on-complete on-error :response)) ; <---
#?(:clj
([interceptors request]
(some-> (execute-ctx interceptors {:request request})
:response)))) ; <---
|
I ended up just adding @den1k I've added you as a collaborator to my fork, please feel free to help with updating/expanding the test suite and testing in general. I'd love to get this into a place where it could be considered for inclusion in Sieppari itself but also only have limited time to hack on this... |
@martinklepsch I'm in the same boat time-wise at least until the end of this week. However, it looks like you already made changes to src + tests. Is this ready for review? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking great! merge
is kinda illegal for any performance critical code, instead, we could use two different Record impls, one for Request/Response things, another for the raw impl.
([initial-context queue] | ||
(merge (new Context nil queue nil nil nil) initial-context)) | ||
([initial-context queue on-complete on-error] | ||
(merge (new Context nil queue nil on-complete on-error) initial-context))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
merge will sadly kill all performance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests don't pass.
closing in favor of #31 |
This tries to address some of the requests (#15 & #28) for a more context focused API (i.e. without the request/response concepts).
execute-ctx
still returns only the:response
value but that's probably something we can figure out.The main goal here is that we can move forward with a Context-based API while maintaining the previous request/response style for backwards compatibility.
cc @dspiteself @jjttjj @den1k