Fork me on GitHub
#pathom
<
2020-10-20
>
ianjones13:10:41

Hey, could anyone point me to an example on how to wrap a rest api in pathom for a Fulcro app?

ianjones13:10:04

thank you! im doing the flux challenge just to wrap my head around fulcro pathom and really hit a road block because most of the examples assume you want graphql or are talking to a db

ianjones14:10:36

@U2J4FRT2T do you have a blog or anything where you write about things? Iโ€™d subscribe ๐Ÿ‘€

ianjones01:10:06

I got it working! Thanks for the help yโ€™all

yenda15:10:23

Currently pathom returns only one result for the same mutation, for instance if the user has a connection issue and the query grows into calling the same mutation with different params twice, I only get the result of the last one. Is there a way to have both or could it be included in a future version?

wilkerlucio20:10:20

what you mean by query grows into calling same mutation with different params? in case of a retry isnt it a different request?

tekacs23:10:23

@U066U8JQJ I think I came here to ask this exact question myself, too ๐Ÿ˜†

[(send-message {:message/text "hey"})
 (send-message {:message/text "there"})]

#_=>

{send-message {:message/sent "there"}}
that's just an example, but the gist is that with mutations sitting at the root (and you can't AFAICT join them under placeholder prefixes either), if you send a query that uses (send-message ...) twice, there's not an obvious way to capture the return values from both of those mutations, since they both write into {send-message ...} at the top level. Does that make it clearer?

tekacs23:10:37

I would do this or something similar if I could:

[{:>/first (send-message ...)}
 {:>/second (send-message ...)}]
but that comes out as an invalid join or maybe something like this, possibly?
[{(send-message ...) {:>/first [:message/sent]}}
 {(send-message ...) {:>/second [:message/sent]}}]
but that just yields an empty result map, like this:
{send-message {}}

wilkerlucio12:10:32

hello, for your case @U0H98U6SY, you can go around this limitation by writing a mutation that sends multiple messages at once

wilkerlucio12:10:47

or, some sort of mutation that composes other mutaitons

yenda14:10:32

@U066U8JQJ I merge queries into one until it can be sent, on retry it does one single query with all the pending ones

๐Ÿ‘ 3
tekacs17:10:59

right, what yenda said @U066U8JQJ

tekacs17:10:13

merging them into one doesn't really help, because it'd break ordering for one thing

tekacs17:10:22

[(mutation-1)
 (mutation-2)
 (mutation-1)]

tekacs17:10:51

the only real option as far as I can tell is to manually split the mutations externally to Pathom and then to send them into the engine one at a time ๐Ÿ˜ž

tekacs17:10:32

I guess I could write a mutation that composes other mutations...

tekacs17:10:09

but would be wonderful if there were an ad-hoc way of simply giving each mutation its output name

yenda17:10:01

which is why I was wondering if it could return a collection of results when the mutation was called more than once

yenda17:10:52

if I'm not mistaken that would not even break existing queries, since for instance

(defn block-user
  [user-id blocked?]
  {(list 'block-user {:user/id user-id
                      :user/blocked? blocked?})
   [:user/id
    :user/blocked?]})
could anyway receive either one map or a coll of map

tekacs18:10:05

if we could rename outputs, then we could get the same effect as a collection by transforming queries to/from a form with renames

tekacs18:10:10

that's why that'd be my aim

tekacs18:10:21

I might see if I can do that in a plugin

yenda18:10:43

If I'm not mistaken the overwrite occurs in mutate and mutate-async when the result is merged in the env

yenda18:10:48

mhm actually looks like it's in the parser

yenda18:10:09

(recur (assoc res (ast->out-key ast) value) tail)

yenda18:10:50

would it be acceptable to do

(let [out-key (ast->out-key ast)
      previous-res? (get res out-key)]
  (recur (if previous-res?
           (update res out-key (fn [previous-res]
                                 (if (vector? previous-res)
                                   (conj previous-res res)
                                   [previous-res value])))
           (assoc res out-key value)) tail))

wilkerlucio18:10:00

@U0DB715GU the vector thing is a problem, because it breaks the assumption that mutations always return a map, I think a behavior like that could be confusing. there is a plugin entry point that I've been considering for a while, and I think it could solve this problem, is a ::p/wrap-output, something to run exactly when pathom is building the output, with this hook you could either write a plugin to use some param and have some different output name (like alias works for reads today) or even make what you are suggesting. this was planned for Pathom 3, but I can make in Pathom 2, this can also give some room to experiment with this entry point

yenda18:10:59

yeah the plugin way would be satisfying enough, I had the assumption mutations would return a vector when ran more than once like resolvers when they return more than one result ๐Ÿ˜„

yenda18:10:01

It could return a vector of results in the mutation key?