Fork me on GitHub
#code-reviews
<
2020-11-25
>
athomasoriginal01:11:07

I have a sample of two possible directions for an HTTP Client API https://gist.github.com/athomasoriginal/bfcb1e6e9e9bc9d318725a6e7d9315b8 - anyone have a preference and what’s your thought process? :thinking_face:

phronmophobic01:11:35

this might be a good question for #architecture. I personally might prefer option #2, with the caveat that if the first argument is a string, treat it as a url. additionally, I wouldn't have an :opts key, I would just have whatever keys that would be pass as part of :opts be part of the map passed in.

phronmophobic01:11:11

although V1 is pretty alright too.

phronmophobic01:11:45

I do like the fact that you can build a map that represents the full request rather than having a url + options as separate pieces that represent a request. it makes request "building" easier

athomasoriginal01:11:54

@U7RJTCH6J Architecture! That’s the channel I was looking for 😜

😁 3
athomasoriginal01:11:30

> might prefer option #2, with the caveat that if the first argument is a string I had the same thought as I was typing it out. I was also toying with the idea of being able to call the same get function as

(-> (get "url" opts) (.then) (.catch))

;; or

(get {...})
With the idea being we check if the first arg is a string which would make it user’s choice, but I was then worried maybe it’s overcomplicating things

athomasoriginal01:11:09

> I wouldn’t have an `:opts` key Also agree that I might want to flatten it out