Fork me on GitHub
#pathom
<
2019-04-15
>
thheller15:04:33

@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?

thheller15:04:07

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

thheller15:04:31

so the output is huge for no reason 😛

wilkerlucio15:04:02

@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

wilkerlucio15:04:23

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

wilkerlucio15:04:50

maybe something like CLOJURE_SPECS_DISABLE

thheller15:04:53

the best option would moving the specs into a separate namespace

thheller15:04:02

but that gets a bit icky with namespaced keywords

wilkerlucio16:04:40

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

rschmukler19:04:51

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?

wilkerlucio19:04:20

you mean ::pc/batch? true?

rschmukler19:04:44

It seemingly only applies to the first item in the batched response

wilkerlucio19:04:02

interesting, yeah, please open an issue, that's not intended

rschmukler19:04:24

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!

wilkerlucio19:04:36

comment replied 😉

rschmukler19:04:49

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.

wilkerlucio19:04:46

I guess I did replied already, I'm missing some other comment?

rschmukler19:04:23

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?

rschmukler19:04:47

(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 🙂 )

wilkerlucio19:04:42

I mean, I replied on Github, did you saw that there? I'm confused on which point of the discussion you are

rschmukler19:04:26

I saw! And again, sorry, I must be missing something

rschmukler19:04:34

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?

wilkerlucio19:04:35

ok, I may understand now, so yes, for the cached-async calls you need to send p

wilkerlucio19:04:46

is that what you pointing to?

wilkerlucio19:04:30

cool, that's right, those calls still need p, my suggestion will be to remove from cache-batch and its calls

rschmukler19:04:44

Okay! Will do!

rschmukler19:04:57

Ready for re-review when you are! Thanks again for the responses.

wilkerlucio20:04:40

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!

wilkerlucio19:04:58

@thheller do you wanna do it? or maybe file an issue so we keep tracking it

thheller19:04:49

@wilkerlucio too swamped with other stuff currently. happy to do it when I find some time though. https://github.com/wilkerlucio/pathom/issues/90

👍 12