This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-04-15
Channels
- # announcements (10)
- # beginners (113)
- # calva (2)
- # cider (75)
- # clj-kondo (1)
- # cljdoc (2)
- # clojure (142)
- # clojure-europe (11)
- # clojure-gamedev (6)
- # clojure-italy (7)
- # clojure-nl (8)
- # clojure-spec (3)
- # clojure-uk (50)
- # clojurescript (47)
- # cursive (7)
- # data-science (22)
- # datomic (12)
- # dirac (3)
- # events (1)
- # fulcro (114)
- # gorilla (1)
- # jackdaw (5)
- # joker (3)
- # kaocha (10)
- # leiningen (1)
- # liberator (2)
- # mount (6)
- # nrepl (1)
- # off-topic (16)
- # pathom (34)
- # pedestal (3)
- # re-frame (19)
- # reagent (11)
- # remote-jobs (5)
- # shadow-cljs (127)
- # spacemacs (12)
- # test-check (15)
- # tools-deps (8)
- # vim (4)
@wilkerlucio would you be open to making all the specs in .pathom.connect
conditional? something like (when SPECS ...)
and with a goog-define
or so?
currently pathom adds up to almost as much code as cljs.core
in :advanced
and the specs aren't used there as far as I can tell
@thheller oh, that's a fair point, I think I'm ok adding that, but just in the opposite direction, we can make a flag to disable the specs
maybe we could even try to make some generic name for it, I guess you may want to remove the ones from eql
as well
maybe something like CLOJURE_SPECS_DISABLE
yeah, my main motivation for putting it togheter was always about convenience of reduced number of requires, but considering this size problem in cljs I may change my policy
Hey @wilkerlucio, regarding your comment yesterday on :pathom/as
for aliasing responses, it seems that that doesn’t work with ::pc/bulk? true
- is that intended? If not, should I open an issue?
you mean ::pc/batch? true
?
Yes, sorry!
It seemingly only applies to the first item in the batched response
interesting, yeah, please open an issue, that's not intended
Okay! Also, thanks for your response on https://github.com/wilkerlucio/pathom/pull/88 - still waiting for a bit more clarification but happy to help if I can!
comment replied 😉
Hey @wilkerlucio if you have a second to discuss that PR, let me know - I’m absolutely happy to change it, I just wan’t to make sure I understand correctly.
I guess I did replied already, I'm missing some other comment?
No, sorry, I just figured it might be faster to discuss on Slack. Specifically, won’t just adding it to the cache-batch
function only make param caching work for batch requests? Also, won’t that mean that if it was resolved in a non-batch fashion earlier, it won’t be used if its later resolved in a batch? ie. Won’t one of them use params, and one of them not?
(And I’m totally happy to implement it that way, I just want to make sure that you’re okay with that, and that I’m not misunderstanding this code so that I can help more in the future 🙂 )
I mean, I replied on Github, did you saw that there? I'm confused on which point of the discussion you are
I saw! And again, sorry, I must be missing something
Consider that line - isn’t that necessary such that the parameters get considered (and not collide) so that the inner body is even run a second time?
ok, I may understand now, so yes, for the cached-async
calls you need to send p
is that what you pointing to?
cool, that's right, those calls still need p
, my suggestion will be to remove from cache-batch
and its calls
sounds good?
Okay! Will do!
Ready for re-review when you are! Thanks again for the responses.
thanks! I did a quick look and seems good, I wanna do some manual checks, probably some time during this week and then we can get it in, thanks for the work!
@thheller do you wanna do it? or maybe file an issue so we keep tracking it
@wilkerlucio too swamped with other stuff currently. happy to do it when I find some time though. https://github.com/wilkerlucio/pathom/issues/90