I’d be interested to know more about what you’re trying to do. Do you have an example? If you’re wanting to output arbitrary attributes and feed them into other resolvers, then I’m not sure it could work. Pathom will make a plan using explicitly defined inputs and outputs. It wouldn’t know how to execute the graph if arbitrary attributes are being returned that aren’t specified.

yeah, would be good to understand what you are trying to do

wrap-resolve and wrap-merge-attribute run in very distinct phases, so you can't have a mapping 1-1 with them, for example, a resolver that returns 5 attributes will have a single call to wrap-resolve, while it will make 5 calls to wrap-merge-attribute

Hi @U066U8JQJ and @U3XCG2GBZ; apologies for the late response. I would like the output of a resolver be dependent on it’s inputs. Concretely (and I’m not sure if this is ultimately a good idea or not), I have a resolver that returns the data for a table of items. The items themselves have raw attributes (i.e. from a database entity) and derived attributes such as formatted values that are resolved by other resolvers. Now, I would like to sort the table before returning it and I would like to sort on the formatted values. I would like to do the sorting, in a sense, by operating on the result of the resolver (like ::pcr/wrap-resolve would allow me to do in a plugin or just in the body of the resolver) but I need the other (derived) attributes merged in. Does that make sense?

same ways as resolvers, using the 2 args, env is the first

Thank you! => https://github.com/wilkerlucio/pathom3-docs/pull/42

thanks, merged!

+1 I found this super confusing that the order of the parameters is reversed with two args vs one. My default intuition was that the environment would be the first argument for 1-arity as well as 2.. soooo confused at first hah

I can see that. Though it makes sense from the UX perspective because you will almost always need the params argument, while env only sometimes (with the exc. of global resolvers and similar). Fortunately the docs are getting ever better 🙂

I just always provide two arguments now using the _ as needed. One less thing to think about.

I think that always require the _env is simpler to understand.

the 0 - 2 is purely a convenience, its better to think that with 1 the env is being removed, as opposed to think you add env with 2

the order will not change (for compatibility), pathom 2 also has the same arity order, which makes them compatible

the reasoning, as @U0522TWDA pointed out, is because its more common to need input without env than the other way around, so pathom provides arity 1 for those cases, there also times you don't care about env or input, then you can go with zero args

note these suggar features are only available in the defresolver & defmutation macros, using pco/resolver and pco/mutation requires the usage of arity 2 every time

the macros will generate an arity 2 fn anyway, this is only real signature for resolvers and mutations (its never a multi-arity fn)

I'm just thinking from API design point of view - reordering parameters is definitely confusing: see slide 34 (https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/32713.pdf)

especially b/c they're both hashmaps. But good to know about this background, agreed with Jakub updating the docs will help with this. And good to know I can just use pco/resolver and write my own macro with consistent parameters

re-ordering is a way to see it, if you think multi-arities add to the end, this is contrived but I don't see different arities this way at all, to me each different arity is like having a different function (which is what actually happens, in cljs for example), in that sense, there is no guarantee or expection that must hold between different arities

one example that we use often is reduce, that in the arity 4 adds a thing at position 3

yea my mental model is (defresolver [env args]) and (defresolver [env])