Fork me on GitHub
#pathom
<
2020-06-01
>
markaddleman02:06:37

My data is naturally hierarchical: events have attributes and attributes have attributeValues And the user walks that hierarchy in the UI by first select an event, then attribute and then an attribute value. It seems like I should be able to construct a pathom query like this

[{[:event "an event"] [{[:attribute "some attribute"] [:attributeValues]}]}]
But this resolver doesn't get invoked:
(pc/defresolver event-attribute-values [env input]
  {::pc/input  #{:event :attribute}
   ::pc/output [{:attributeValues [:attributeValue]}]}
  (println "event-attribute-values" input)
  {:attributeValues (into [] (select-keys-distinct [:attributeValue])
                          (es/list-result! [:attribute-values-v1] env input))})

markaddleman02:06:16

I read in the docs that I can provide a pathom/context map but that seems contrary to the idea of a graph query.

markaddleman02:06:29

I think it's interesting that this query resolves:

[{[:event "Sign In Forgot Password Submitted"] [{:attributes [:attribute :path :attributeValues]}]}]

markaddleman02:06:07

I expect that I could provide an ident in the place of :attributes

markaddleman02:06:14

Am I thinking of pathom wrong?

Andreas Edvardsson06:06:04

Iā€™m not very skilled in Pathom but what happens if you put all the context together?:

[{[:event "an event"
   :attribute "some attribute"] [:attributeValues]}]

markaddleman14:06:11

Thanks but that doesn't work either because an ident is defined as a vector with two elements.

markaddleman14:06:43

I did play around with a new reader that accepts a map as an ident instead of a two-element vector. It seems to work but I have more playing to do šŸ™‚

sergey.shvets19:06:34

Pathom won't pass your :event attributes to the second join automatically. You need to do it manually. Just make sure that inside your :event resolver you pass down the :event property. You need to modify your event-attribute resolver to return :event that I assume it gets as an input.

sergey.shvets19:06:23

I now do it for every "join" resolver and it allows me for pretty much unlimited nested joins

markaddleman19:06:37

Thanks for the insight. I'm pretty new to pathom - Can you give me an example of passing the event attribute to the second join?

markaddleman19:06:19

Do you mean that it's the responsibility of the resolver?

markaddleman19:06:56

I updated my resolver to pass along :event and now it works like I expect. Thanks!

sergey.shvets20:06:42

Yes. I would vote for having this done by pathom, but for now it is responsibility of a resolver to do so.

markaddleman20:06:57

Yeah, I agree with your vote šŸ™‚

markaddleman20:06:03

I ran into a related problem:

markaddleman20:06:21

I have two resolvers one with output

[{:attributes [:attribute :attributeType :dataType :path :event]}]
and another with output
[{:attributes [:attribute :attributeType :dataType :path]}]
(the only difference is that one produces :event and the other doesnot

markaddleman20:06:12

This reflects two different locations of :attributes in my graph: one set of attributes is global for the entire UI while the other set of attributes is event-specific

markaddleman20:06:13

This query gets handled by the event-specific resolver:

{:events [:event {:attributes [:attribute :ui-location :dataType :path :attributeValues]}]}

markaddleman20:06:38

But this one gets resolved by the global resolver:

{[:event "My Savings Coupon Edited"] [{:attributes [:attribute :ui-location :dataType :path :attributeValues]}]}

markaddleman20:06:28

The obvious solution is to have two separate attribute lists, :global-attributes and :event-attributes

sergey.shvets20:06:51

yes, I think this is the best way to solve it. Alternatively, you can pass the proper resolver type as a param, but that is way more uglier, imo

markaddleman20:06:16

Thanks for the pointers!

sergey.shvets20:06:48

You welcome. I'm pretty new to pathom as well, but Wilker was super helpful and helped me solve the exact same problem couple of weeks ago

šŸ‘ 4