This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-29
Channels
- # announcements (4)
- # architecture (25)
- # babashka (23)
- # beginners (56)
- # boot (4)
- # calva (1)
- # cider (1)
- # cljs-dev (15)
- # clojure (135)
- # clojure-europe (4)
- # clojure-nl (21)
- # clojure-uk (61)
- # clojurescript (47)
- # community-development (4)
- # cryogen (11)
- # cursive (11)
- # data-science (11)
- # fulcro (25)
- # funcool (5)
- # graalvm (1)
- # graphql (4)
- # kaocha (4)
- # lambdaisland (20)
- # lumo (7)
- # meander (14)
- # off-topic (9)
- # pathom (2)
- # portkey (1)
- # re-frame (5)
- # reagent (53)
- # reitit (2)
- # ring (3)
- # shadow-cljs (32)
- # spacemacs (4)
- # sql (34)
- # testing (1)
- # tools-deps (3)
I'm curious to know what coffee grinders offer which interceptors do not. I don't see them as more general than interceptors, they appear to be interceptors.
an interceptor is a coffee grinder but not the other way around. Nothing of what I show in that blog post is an interceptor.
interceptors in particular have the enter/leave/error split, and the queue+stack, and a strong assumption that you're dealing with request->response (e.g. in Sieppari you can't just give it a context, you have to start from a request). So they're a specialized case that assumes you're doing http request handling. My point is that you can boil that down to its essence, and then do different things with it.
Sieppari seems to work with an arbitrary context. For example, the read me uses {:x 1}
Hmm, so with sieppari, the reasoning is that it doesn't take the queue as part of the map it is initially given? It takes a M & a queue separately?
The distinction between what? I feel like you're asking me to explain to difference between rats and rodents, or between OO and Java
It's different from that. I understand the distinction between interceptors and sieppari. I don't understand the distinction between coffee grinders and interceptors. Coffee grinders are interceptors without enter/leave, and the API is focused on a context instead of a request?
Or look at the definition at the top of the post, and see if you can imagine something that adheres to that that is not interceptors
My main point is that instead of only using a few specific implementations for a few specific use cases people should be encouraged to see the general pattern, and how variations of it can be applied to many different use cases.