Nei:

(let [request {:headers {"Accept" "application/foo"
                         "Content-Type" "application/json"
                         "Authorization" "token my-access-token"}
               :query-params {:organization "my-org"}}]
  (assoc-in request [:query-params :continuationToken] "continuation-token"))

Hehe! Det ante meg at jeg gjorde noe tungvindt der, ja.

Du trenger forøvrig ikke på bruke update-in når du bare har ett element i vektoren. Da kan du heller gjøre (update m :query-params f)

Typ når man ikke har en nøsta struktur med maps-i-maps?

Ja, hvis du bare vil oppdatere verdien til en key rett i mappet, sånn som du gjorde over der

Altså:

(update-in request [:query-params] merge {:continuationToken "token")

(update request :query-params merge {:continuationToken "token"})

Aha, jeg forvekslet begrepene "legge til" og "oppdatere," men det er vel synonymer i denne konteksten ("legge til" er også en "oppdatering" av mappet en begynner med).

{update,assoc}-in-variantene er for gjøre ting i nøsta strukturer

Flere måter å oppnå samme resultat:

(assoc-in request [:query-params :continuationToken] "token")
(update request :query-params assoc :continuationToken "token")

Nice, takk! "`*-in` er for nøsta" er en fin tommelfingerregel.

Jeg var ikke klar over at en kunne bruke en vektor med keywords på den måten får å "rusle nedover i maps." Det er jo veldig praktisk!

Veldig 😄

Hvis du ikke skal det trenger du ikke *-in

Nå gjør jo alle disse til slutt det samme, men jeg mener assoc-in-varianten er den som tydeligst kommuniserer hensikten din

Disse er spesielt nyttige sammen med thread first:

(let [request {:headers {"Accept" "application/foo"
                         "Content-Type" "application/json"
                         "Authorization" "token my-access-token"}
               :query-params {:organization "my-org"}}]
  (-> request
      (assoc :method :get)
      (assoc-in [:query-params :continuationToken] "continuation-token")
      (assoc-in [:headers :lol] "lol!")))

kan være fint å blande update og assoc noen ganger og. Eks:

(-> thing
    (update :style assoc 
       :color "#fff" 
       :font-weight "bold"))

(what Christian said)

Ja, jeg prøvde å vise en blanding av update/update-in/assoc/assoc-in, men fantasien min sviktet meg 😂

Kriminell formattering der @U0MKRS1FX!

haha ja sorry, sånn går det når Slack er editoren og jeg ikke har paredit

Og sånn bare for ordensskyld. Jeg er av den klare oppfatning at https://en.wikipedia.org/wiki/Law_of_Demeter også gjelder for Clojure. Det betyr at hvis du enten gjør: (update-in x [:foo :bar :baz 0 :qix] eller begynner å synes at specter ser bra ut, så gjør du noe feil.

Enig! Det er mange gode use cases for update-in og assoc-in med to nivåer (som eksemplifisert over), men så faller det bratt deretter

ah, fint at den tingen der har et navn. Jeg kaller det “skrive til nøsta data er et rødt flagg”

Jeg kom innpå temaet fordi jeg oppdaget at man kan bygge opp HTTP requests som rene maps på denne måten:

(ns pulumi
  (:require [cheshire.core :as json]
            [org.httpkit.client :as http-kit]))

(def base-uri "")

(def access-token "X")

(def headers
  {"Accept" "application/foo"
   "Content-Type" "application/json"
   "Authorization" (str "token " access-token)})

(defn fetch-stacks [request callback]
  (http-kit/request (assoc request
                           :url (str base-uri "/api/user/stacks")
                           :method :get)
                    callback))

(def base-request
  {:query-params {:organization "my-org"}
   :headers headers})

(defn parse-response [response]
  (-> (:body response)
      json/parse-string))

(def stacks (fetch-stacks base-request parse-response))

(get @stacks "continuationToken")

Og da måtte jeg finne noen måter å "gradigvis bygge opp" request maps.

Det som kan være fint er:

(update foo :lol my-fn-that-knows-about-lolz :bar :baz)

Enig i prinsippet, men jeg syns eksempelet med http requests er et godt eksempel på fin bruk av assoc-in. Det er ikke å forgripe seg å vite at inne i headers ligger det headere.

Enig i det.

Nå prøver jeg å finne ut hvordan jeg kan legge til continuation-token som et optional parameter til fetch-stacks funksjonen min, sånn at jeg kan hente alle batches/"pages" fra API-et til Pulumi ved hjelp av iteration 😁

Med if kan det bli:

(if continue?
  (assoc-in request [:query-params :continuationToken] "continuation-token")
  request))

(cond-> request
  continue? (assoc-in [:query-params :continuationToken] "continuation-token"))

(-> m
  x
  y)

(cond-> m
  true x
  true y
  continue? …)

eller

(-> m
    x
    y
    (cond-> continue? z))

Snedig!

det er nesten som om Rich har tenkt litt når han satte sammen disse byggeklossene til oss 😄

cond-> i threading-macro er supert!

Jeg må si at akkurat som med veldig smarte destructurings, så sliter jeg litt med smarte threadings også…

Enig i det, men den siste til Magnar kunne jeg ha brukt

Dumt spørsmål: I eksempelet ditt, @U0523NZUF, er continue? en predicate-funksjon som sjekker hvorvidt en continuation token eksisterer i responsen?

Jeg laget forresten en Gist med koden min her 🙂 https://gist.github.com/leifericf/2574d715a938b9fb0e98418ba4d77f36

Siden du skal bruke iteration, bruker du :kf for å lese ut continuation-token fra responsen til foregående step:

(iteration step :kf (fn [response] (:continuationToken response)) ...)

(defn step [continuation-token] …)

(cond-> request
        continuation-token (assoc-in [:query-params :continuationToken] continuation-token))

(defn step [& {:keys [access-token]}]
  ;; setup og returner faktisk step-fn
  (fn step* [continuation-token]
    (let [request {:headers {"Authorization" (format "token %s" access-token)}}]
      ...)))

(defn headers [& {:keys [access-token]}])
(defn base-request [& {:keys [access-token]}])

(fn step* [continuation-token]
    (let [request (cond-> (base-request :access-token access-token)
                          continuation-token (assoc-in [:query-params :continuationToken] continuation-token))]
      ...))

(defn with-continuation-token [request continuation-token]
  (cond-> request
          continuation-token (assoc-in [:query-params :continuationToken] continuation-token)))

(defn base-request [& {:keys [access-token continuation-token]}])

(fn step* [continuation-token]
  (post (base-request :access-token access-token :continuation-token continuation-token)))

Super nitpick:

:kf :continuationToken

Vakkert:)

Tusen takk for tipsene! Jeg sliter litt med å henge med, må lese litt sakte og teste det ut her.

La igjen en liten kommentar på gist’en

Det kan du gjøre til krampa tar deg, men den er immutable 🙂

Du må huske på at du jobber med immutable data 🙂

Du endrer ikke på request, du lager en ny request - som du sporenstreks kaster fra deg

Du får deg en ny versjon request som du bare kaster 🙂

Seems to be an echo in here 🙂

😂

(defn get-page! [continuation-token]
  (-> stack-request
      (cond-> continuation-token
        (assoc-in [:query-params :continuationToken] continuation-token))
      (http-kit/request response-body->json)
      deref))

z0Mg!

Jeg ville jo kanskje hatt den testen på continuation-token på utsiden av denne funksjonen?

Det er jo det eneste den gjør 😄

mnja, det kan man si, men den mekker jo egentlig en request og så utfører den requesten.

Ja, egentlig ville jeg sende inn request map som parameter også, men da får jeg ikke bruke get-page! med iteration (`step` må ta ett parameter).

partial 🙂

Oh, my! Ja, så klart.

Evt #(get-page! stack-request %) (som er det samme)

Det er egentlig utrolig frustrerende å vite om alle disse bitene som kan komponeres, men ikke være smart nok til å tenke på dem og sette dem sammen riktig 😂

Det tar tid å få god nok oversikt, og ha dem i fingertuppene 🙂

Med en gang dere svarer, tenker jeg "så klart!" og "gudbedre så tafatt og bakstrebersk jeg er" haha!

Tror forøvrig at @U9MKYDN4Q sin cond-> ikke er helt riktig?

Joda, bare litt snålt formattert

Jepp. fintekode.

Gjorde du det med vilje?

Hvorfor bruker man forresten deref istedenfor @? :thinking_face: Er det bare en smakssak?

Går sikkert ikke å threade inn i @ siden det sikkert er en (reader) makro

Stemmer

Ahaaa, right.

@slipset tja, det ble seende litt rart ut uansett. godt mulig man ikke burde drive med det der med mindre det går på en linje

Jeg syns det leser helt fint 🤷

jeg leste nemlig at du thread’a continuation-token hvilket ikke gir mening.

Ja, jeg ser den

i likhet med andre former i en -> så må man ha med seg at man er i en ->

Joda. Men jeg er enig i at threading inni threading er "pushing it"

Men jeg er ikke så glad i if inni threading heller

Jo, men det hadde nok vært mer åpenbart (for meg) hvis det hadde vært

(cond-> 
   continuation-token (assoc-in ...))

Da må @U01PE7630AC slutte å ha så lange navn 😄

langt å foretrekke over en drøss med true i en topp level cond-> i hvert fall

det er ikke et alternativ i min bok

My final offer:

(defn get-page! [token]
  (-> stack-request
      (cond-> token (assoc-in [:query-params :continuationToken] token))
      (http-kit/request response-body->json)
      deref))

(defn get-page! [token]
  @(http-kit/request (cond-> stack-request 
                         token (assoc-in [:query-params :continuationToken] token)) response-body->json))

Jeg er litt kjølig innstilt til så bred kode 😅

Modulo linjeskift da 🙂

Haha, jeg tenkte det samme "den var brei" 😅

Jeg er heller ikke noen fan av at et argument "midt i" er over flere linjer

Men, jeg tror min største insigelse er at jeg ville nok hatt stack-request som param.

Jeg ville heller formattert det sånn i så fall:

(defn get-page! [token]
  @(http-kit/request
    (cond-> stack-request 
      token (assoc-in [:query-params :continuationToken] token))
    response-body->json))

Mye av dette ville jo vært ungått dersom man hadde brukt et ikke-async http-client bibliotek

Men jeg liker threading-varianten bedre

> Da må @U01PE7630AC slutte å ha så lange navn 😄 Yrkesskade fra C# 😂

Alt over tre bokstaver kommer med en viss skam for ekte lisp-folk 😁

cnt-tok

Har en kar som puster meg i nakken, men skal bytte til et av Babashka sine innebygde ikke-async HTTP klienter etter jeg har fått det til å funke.

Bryr vi oss egentlig om hva slags token det er?

altså, jeg vil si at du “overspesifiserer” navnet til tokenet.

Nei, derfor kalte jeg det token

Mitt forrige forslag var en spøk

Det ble slik for nå:

(defn get-page!
  ([] (get-page! nil))
  ([token]
   (-> stack-request
       (cond-> token (assoc-in [:query-params :continuationToken] token))
       (http-kit/request response-body->json)
       deref)))

Eventuelt:

(defn get-page! [& [token]]
  (-> stack-request
      (cond-> token (assoc-in [:query-params :continuationToken] token))
      (http-kit/request response-body->json)
      deref))

Sikkert mikroskopisk dårligere ytelse, men tipper den forskjellen spises opp av nettverksaktiviteten der 🙂

Clean!

& args og destructuring er også greier jeg sliter litt med å forstå og bruke smart.

Jeg er litt var for bruk av ulike former for multi-arity fns fordi da plukker ikke clj-kondo opp at jeg gjør feil.

Er det en villet mangel i clj-kondo? Jeg har merka det sjøl, virker som om den ikke skjønner multi-arity

Ahaaa, det forklarer visse squigglies i koden min.

Jo, men hvis du har en (defn foo [& opts]...) så er det jo ingen mulighet å sjekke for at du har med deg noe som helst. (defn foo [opt1 opt2 opt3]…) sier jo at du krever disse tre opt’sene

Ja, men om du gir funksjonen to signaturer sånn @U01PE7630AC gjorde først så syns clj-kondo at alt er dritt

Hmm, det har ikke jeg merka.

Kult! Nå funker iteration! Wohooo! Men den henter visst kun den første siden 😛 Så det er noe rart der.

(def all-stacks (iteration get-page!
                             :vf #(get % "stacks")
                             :kf :continuationToken))

{"stacks"
 [{"orgName" "my-org",
   "projectName" "my-project",
   "stackName" "my-stack-1",
   "lastUpdate" 1692103259,
   "resourceCount" 14}
  {"orgName" "my-org",
   "projectName" "my-project",
   "stackName" "my-stack-2",
   "lastUpdate" 1695911748,
   "resourceCount" 16}
  {"orgName" "my-org",
   "projectName" "my-project",
   "stackName" "my-stack-3",
   "lastUpdate" 1700757647,
   "resourceCount" 14}
  ...],
 "continuationToken"
 "XYZ"}

Aaaah! Kanskje fordi "continuationToken" er en string og ikke et keyword (`:continuationToken`) i responsen!

Du må sørge for at response-body->json mapper keys til keywords

Dette funka fett!

(def all-stacks (iteration get-page!
                             :vf #(get % "stacks")
                             :kf #(get % "continuationToken")))

Men, ja, sikkert penere å gjøre konvertering fra strings til keywords utenfor.

(defn response-body->json [response]
  (-> (:body response)
      (json/parse-string keyword)))

Altså, dette er bare heeelt rått.

(def all-stacks
    (iteration get-page!
               :vf :stacks
               :kf :continuationToken))

  (def stack-names
    (->> all-stacks
         seq
         flatten
         (map :stackName)
         sort))

Kjør på med en (mapcat :stackName) 🙂

LOL

Og du trenger vel ikke seq hller?

Det tar aldri slutt med improvements. Må digge Clojure.

Og du trenger vel strengt tatt ikke def’e all-stacks lenger?

http-kit/request returnerer en "promise." Jeg måtte konvertere den til en seq for å gjøre mer med den.

Jo, men kan du ikke bare deref’e rett på http-kit/request ?

iteration mente jeg

Ah, ok.

Jeg fikk ikke lov til å gjøre flatten på det iteration gav meg.

(->> (iteration get-page! :vf :stacks :kf :contunuationToken) seq (mapcat :stackName) sort)

Dette er jo faktisk ganske så nice 🙂

Hmmm, mapcat returnerer nil

Meep! Det er jeg som tenker feil

Det funker ikke med mapcat.

Nå med request map som parameter!

(defn get-page! [request & [token]]
  (-> request
      (cond-> token (assoc-in [:query-params :continuationToken] token))
      (http-kit/request response-body->json)
      deref))

(get-page! stack-request)

(iteration (partial get-page! stack-request)
             :vf :stacks
             :kf :continuationToken)

En liten hjelper (for mine kollegaer som ikke kan Clojure) 🙂

(defn get-all-pages! [request token-key]
  (iteration (partial get-page! request)
             :vf :stacks
             :kf token-key))

partial funker utmerket slik du bruker den her, når du også ønsker å bruke get-page! i andre sammenhenger (hvorfor utropstegn på get?). Hvis du kun skulle bruke den som step-fn, kunne du også gjøre det slik:

(defn get-page! [request]
  (fn [token]
    (-> request …)))

(iteration (get-page! stack-request) :vf …) 

hvorfor utropstegn på get?Jeg trodde det var god praksis å bruke ! på funksjoner med sideeffekter, og jeg trodde get-page! var en slik 😅 Men når jeg tenker meg om har vel mine fleste funksjoner sideeffekter fordi dette er Babashka/Shell greier.

http-kit/request har selv ikke noe utropstegn. Utropstegnet er ofte for “destruktive” ting, eller noe sånt? :thinking_face:

“conventional ending for an unsafe operation” sier clojure doc

Jeg bruker ! for skrive-operasjoner ja. Selv ville jeg unngått "get" for nettverks-requests, bruker typ "fetch" eller lignende i stedet

Kanskje dette er litt bedre 🙂 Bort med let i @U9MKYDN4Q’s ånd.

(defn create-permission-request [team permission stack]
  {:headers headers
   :url (format (str pulumi-uri "/orgs/%s/teams/%s") pulumi-org team)
   :body (-> {"addStackPermission"
              {"projectName" (:projectName stack)
               "stackName" (:stackName stack)
               "permission" (permission {:read 101
                                         :edit 102
                                         :admin 103})}}
             json/generate-string)
   :method :patch})

Forbedring! 👍

Jeg prøver å få til destructuring på stack sånn at jeg slipper å gjøre (:projectName stack) og (:stackName stack) 🙂

det tenker jeg er ganske unødvendig - du ender opp med flere "løse" bindinger som ikke øker lesbarheten nevneverdig

men det er altså [team permission {:keys [projectName stackName]}] i tilfelle du vil prøve

jeg er forøvrig glad i ….. eksplisitt destructuring? I mangel på et bedre navn. [team permission {project-name :projectName stack-name :stackName}]

er noe med å kunne greppe etter :projectName jeg har en liten hangup på

Da forsvinner hele poenget med destructuring i mine øyne

Målet er å bli kvitt noen navn og få ting litt mer kompakt. Det der fører bare til Java-style dobbel-navning. Da ville jeg foretrukket å bruke keyword-oppslag uten destructuring.

Men enig i at det er ålreit å kunne greppe etter enkelte ting. Jeg prøver å bruke stadig mer namespaced keys, og er forsiktig med å destructure dem, med samme mål.

Nå også https://www.linkedin.com/feed/update/urn:li:activity:7145749161152352256/ for å promotere Clojure/Babashka litt med et virkelig use case 🙂