Fork me on GitHub

I have a list of notes:

{:note-list/id {:singleton {:note-list/notes [[:note/id 1] [:note/id 2]]}}

{:note/id {1 {...}
           2 {...}}}
I want to import more notes and add them to the list. My server mutation imports them to the backend DB. What graph should it return so that they can be appended to the list? I understand how to add just a single note to the client db and append it to the note-list, but not sure how to do the same with multiple notes.
(pc/defmutation import-notes
  [env {::file-upload/keys [files] :as params}]
  (log/info "Importing notes")
  (let [persist-notes! (partial m/add-note! env)
        notes (->> files first :tempfile read-lines (map ->note))
        ; ids (mapv #(select-keys % [:note/id]) notes)
        fnid (:note/id (first notes))
        ;; testing for just one note; how to change for multiple?
        res {:note/id fnid}]
    (run! persist-notes! notes)
(defmutation import-notes
 (action [{:keys [state]}]
   (log/info "Importing notes")
 (remote [env]
   (let [NoteList (comp/registry-key->class :sheluchin.ui/NoteList)
         Note (comp/registry-key->class :sheluchin.ui/Note)]
    (-> env
     (m/returning Note)
     (m/with-target (targeting/append-to [:note-list/id


Fun one. So, have you tried returning a list of maps (no change to client)?


If that doesn’t work, then it should…I can’t remember the last time I returned a to-many from a mutation


I could have missed this use-case because of tempids…so even if that works, I’m actually pretty sure it is insufficient. What you might have to do at the moment, which is perfectly legal, is to specify the AST of the return type (see the code of returning) and send an extra join in. Normalization will work on that, but targeting won’t, so you’d need to then grab it and merge the idents via ok-action.


let me know…I’ll open an issue on GH, because I did overlook the tempids issue either way in this case


drop your findings there if you would

👍 1

Thanks, will do. It looks like it's not being handled correctly when returning a vector of the maps like:

[#:note {:id #uuid "cc01c445-5540-4241-ae3c-cdcfc93a18c0"}
 #:note {:id #uuid "7d3f53ee-92e1-45a2-9358-59e01f51734f"}]


I don't know the reason why it's happening, but I'm getting the old Warning: Each child in a list should have a unique "key" prop. in the client. I'm presuming it's the result of some mishandling, because I have many other operations around these components that are working with no such issue. Will add it to the ticket.

Jakub Holý (HolyJak)20:10:48

Ah so pathom resolvers must always return a map but mutation do not have this limitation and can legally return a list?


That was unexpected to me as well.


@UPWHQK562 no, that warning is a React one..has nothing to do with this. @U0522TWDA why would you make that assumption? This is a Fulcro-specific issue.


I have not personally tried returning a vector from a mutation in pathom on a mutation join, but I would expect it to work. Could be this is rare enough that no one has tried this particular thing. I sure haven’t

Jakub Holý (HolyJak)07:10:54

Well, resolvers can only return a map so I assumed that's the same for mutstions. Do I understand right that an EQL mutation can actually return a raw [thing1 thing2...]?


in my head I have the assumption that mutation results should also be maps, I don't remember trying to return anything else from them


So, yeah, rare 😄