This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-02-18
Channels
- # adventofcode (18)
- # announcements (1)
- # asami (99)
- # babashka (4)
- # beginners (45)
- # calva (20)
- # cider (44)
- # cljdoc (5)
- # clojure (66)
- # clojure-australia (2)
- # clojure-europe (36)
- # clojure-nl (11)
- # clojure-norway (4)
- # clojure-seattle (1)
- # clojure-uk (88)
- # clojurescript (37)
- # community-development (8)
- # conjure (8)
- # datascript (4)
- # datomic (29)
- # depstar (12)
- # emacs (7)
- # events (1)
- # fulcro (29)
- # graalvm (4)
- # graphql (2)
- # helix (2)
- # integrant (4)
- # jobs (7)
- # jobs-discuss (1)
- # lsp (3)
- # malli (6)
- # off-topic (61)
- # pathom (67)
- # pedestal (3)
- # re-frame (9)
- # reitit (4)
- # remote-jobs (13)
- # reveal (18)
- # shadow-cljs (59)
- # spacemacs (1)
- # sql (7)
- # startup-in-a-month (1)
- # tools-deps (29)
- # vim (12)
We got asked today the possibility to expose our pathom api as a graphql api. i know this has been discussed several times and there are attempts like https://github.com/denisidoro/graffiti but do you think it would make sense to relay on pathom3's smart maps as lacinia resolvers? so basically we would create the graphql schema define the root queries attaching resolvers that use smartmaps
I would avoid smart maps for this use case, doing large queries one attribute at a time isnt very efficient, and some queries will pay more than others
I think there is some work to be done, like Grafitti to improve that story
not on my radar at this time, but I can help if anyone wants to try that direction
Thanks for the input wilker. It's probably something we will need to implement at some point. I can start looking at it, is the graffiti code a good place to start ?
@jmayaalv cool, I just started this discussion in the project, if anyone would like to bring points on how to make a GraphQL interface out of Pathom, we can concentrate resources here: https://github.com/wilkerlucio/pathom3/discussions/18
(please disregard the namespace name - I'm not sure this is a bug 🙂 )
I have a resolver called "dimension-attributes" which can produce an array of raw data which another resolver formats into something - in this example, that formatting has trivial logic in the id-event-level resolver. Finally, I have a resolver field-list which reformats the data into something suitable for the pivot table UI widget
The dimension-attributes resolver can produce an empty array
When the dimension-attributes resolver produces an empty array, the reformatting resolver (field-list) is not invoked and, so, the field-list resolver is not invoked. This results in the wrong data sent to the UI
I've tried various combinations of pco/?
but I cannot find the right combination to get the result I'm looking for.
Am I going about this the wrong way?
the problem is when you return an empty array you’re not returning those keys (`:key`, :some
, and :data
) so pathom won’t be able to invoke the id-event-level
resolver (which is how your field-list’s attribute-id
input can be fulfilled). what would you like the response of (:>/input {:key "empty"})
to be?
Instead of returning a vector would this work?
(pco/defresolver dimension-attributes [{:keys [key]}]
{::pco/input [:key]
::pco/output [{:attributes/dimensions [:key :some :data]}]}
{:attributes/dimensions (when (not= key "empty")
{:key "key"
:some "a"
:data "b"})})
(pco/defresolver id-event-level [input]
{::pco/input [(pco/? :key) (pco/? :some) (pco/? :data)]}
{:attribute/id input})
;; Keep the rest the same
When you return an empty array, there’s nothing for pathom to iterate on which is the real issue with your original code (and why using a combination of (pco/?)
probably wasn’t working).Thanks. I may have oversimplified the real use case. In real life, dimensions-attributes pulls data from a elastic search which may have zero, one or many documents that match a query
I feel like there ought to be a solution on the field-list resolver by using pco/?
but I can't find a magic combination to get the results that I want
@U2845S9KL just did tried here
I believe this has the change you want:
(pco/defresolver field-list [input]
{::pco/input [{:attributes/dimensions [(pco/? :attribute/id)]}]
::pco/output [{:pivot-table/fields [:pivot-table.fields/list
:pivot-table.fields/count]}]}
{:pivot-table/fields {:pivot-table.fields/count (count (:attributes/dimensions input))
:pivot-table.fields/list (mapv (comp (fn [raw] {:pivot-table.field/id raw}) :attribute/id) (:attributes/dimensions input))}})
try with this resolver modified, and let me know if that's expected result now
Thx. I'll give it a try right now
ops. I just noticed this broken the first example ("not empty")
I thought I had tried that 🙂
It's as if pco/?
is causing Pathom to give up too early
Is it expected that we’d need to make it optional? I would think that {:attributes/dimensions []}
would still fulfill:
[{:attributes/dimensions [:attribute/id]}]
its different specifications
I guess in his case, the list is mandatory, but the some parts of the list content are optional
Pathom will only consider a sub-query valid if the required fields there are fulfilled
in that sense, the Pathom behavior is correct in the initial example
because the "empty" case can't fulfill the item detail
altough, this seems a special case up to discussion, over what to do when the collection is empty
in this case, should the input be considered valid, or invalid?
@U2845S9KL changing from required to optional and stop working is for sure a bug, going to work on that in a bit
Thanks! This is one of the last bits for me to switch completely to Pathom3.
(to be clear, this is new functionality - I haven't tried this in Pathom2)
no nested inputs in Pathom 2, you are living the edge here 🙂
I have many comments in our pathom2 code about where we will benefit from nested inputs 🙂
nice, and Im really asking your opinion here
in case of empty collections, what you think would be the most sane default?
consider the input valid, or invalid?
(currently is invalid)
and to make a case for valid, the @U2845S9KL code would work without need for optionality on the fields, if valid was the answer
In my opinion an empty collection is valid b/c it does fulfill the contract. For every item in the collection (zero items) they have an :attribute/id
yeah, I'm tending to that side too
most nested inputs are mostly about aggregation, and aggregation on empty collections most commonly expected to be valid
From my standpoint, it took a little bit of staring to understand why the empty collection was not triggering the id
resolver.
It would have been more natural if it had
awesome! what happens if some of the elements fulfill the nested input requirement but others don’t? I don’t have a real life example, but just curious
in that case its considered a match, but some items may have missing requirements
wonder if would be sane to filter it out
From my standpoint, it would be sane to filter those out. I conceptualize pathom's behavior as a database JOIN operation. If some attributes don't exist on one side of the join, they aren't in the result set
ya, i also think filtering out those missing the required key is sane behavior. if you didn’t want them filtered out i’d imagine you could make the nested key an optional key instead of required
I agree with you guys
valid empty inputs just landed on master! @U2845S9KL you may wanna give a try if you still up 🙂
right after dinner. Thanks!
Works perfectly!
Thank you!
you'r welcome 🙂
so now in cases of collections and parts of the items are missing the requirement, these items are filtered out
Yep. I just updated my code to remove pco/?
. Makes it easier to understand, I think
yeah, and is the correct expression in your case
@jmayaalv cool, I just started this discussion in the project, if anyone would like to bring points on how to make a GraphQL interface out of Pathom, we can concentrate resources here: https://github.com/wilkerlucio/pathom3/discussions/18
nested optional inputs fixed on master
and to finish this up today, nested input filtering just landed on master!