pathom 2022-10-29 | Slack Archive

benny07:10:46

I'm wrapping an API that returns IDs that could either be one "thing" or another. Is there a best practices how to work around that sloppy data structure?

{:name "foo", :contents [{:id 1, :type "person"} {:id 1, :type "group"}]}

I tried to add a content-to-person and content-to-group resolver that returns {:id 1, :type "person"} to {:person/id 1} and {:group/id 1} depending on the :type. But it's not guaranteed to contain a person nor a group so the eql-queries are rightfully barked at, when the data gets returned and a map doesn't contain a mix of both "things." Or would one just add {:person/id 1, :group/id nil} depending on the :type and just return nil for all additional attributes that can't be resolved? I'm lacking a "Maybe" type to query on which would infect my internal data structure. 😐

benny08:10:17

FYI: For now to not get stuck I've opted to use an enveloping type that gets me my relevant attributes. It doesn't feel clean, but for now it gets the job done.

roklenarcic10:10:31

union query?

benny17:10:09

Thanks. Seem like the right thing, except they don't work for me. I'll keep them in mind.

2022-10-29

Channels