Thanks for the update!

This is AWESOME! I’ve been thinking about this + the visualization style for a long time, and it’s really neat seeing it actually used somewhere. Makes me even more interested in working on tooling to simplify these kinds of tools :)

Pathom 3 has support for resolver prioritization https://pathom3.wsscode.com/docs/resolvers#prioritization not sure if available on pathom2.

Thanks, I’ll take a look.

there is a way to do that in Pathom 2, you can set on the env the key ::pc/sort-plan, in this case you must provide your own function to sort the plans, you can find the default impl here: https://github.com/wilkerlucio/pathom/blob/master/src/com/wsscode/pathom/connect.cljc#L621 that said, its usually not trivial to get a specific resolver order from that, that’s why in Pathom 3 it was made different

In my case I have a tournament and its full name property can be resolved by 3 different resolvers depending on which relationship the tournament has with one of organizer, series, and season. Tournament full name is only the tournament name if it is connected to a organizer; tournament + series names if connected to a series; tournament + series + season names if connected to season ( organizer 1:n series 1:n season). I would like to define the order as prioritizing tournament-season, then tournament-series, then tournament-organizer resolvers.

gotcha

modeling wise, I think of this as first having 3 different attributes, one for each name path, the important part is just to be able to talk about them as different things

them, another resolver can ask for the 3 of them, and decide the order based on the available options

in Pathom 3 you can use a resolver with 3 optional inputs and make the choice there, in Pathom 2, since there are no optional inputs, what you can do is make a resolver that depends the most broad of the options (the case most easy to access, so it just enough for the engine to trigger it), and inside of the resolver you can call the parser to fetch the other 2 options

something like:

(pc/defresolver select-name 
  [{:keys [parser] :as env} {:keys [name-opt1]}]
  {::pc/output [:name-choice]}
  (let [{:keys [name-opt2 name-opt3]}
        (parser env [:name-opt2 :name-opt3])]
    {:name-choice
     (or name-opt3
         name-opt2
         name-opt1)}))

Ah, nice! I’ll try to implement it in my code base. By the way, good to know that you are in the Clojure Brasil group. 🙂