Fork me on GitHub

Man, foreign envs/resolvers is about the coolest thing ever.

😄 4

I'm confused why a note-cards-resolver is being called when it doesn't promise the desired fields in ::pc/output:

    [{[:note/id 1]
      [{:note/card-list [:card-list/id]}]}])
(pc/defresolver note-id->card-list-id-resolver
  [{:keys [crux] :as env}
   {:note/keys [id]}]
  {::pc/input #{:note/id}
   ::pc/output [{:note/card-list [:card-list/id]}]}
  (log/debug "note-id->card-list-id-resolver" {:note/id id})
   {:card-list/id (q/note-id->card-list-id crux {:note/id id})}})

(pc/defresolver note-cards-resolver
  [{:keys [crux] :as env}
   {:note/keys [id]}]
  {::pc/input #{:note/id}
   ::pc/output [{:note/card-list [{:card-list/cards [:card/id]}]}]}
  (log/debug "note-cards-resolver" {:note/id id})
  #p {:note/card-list
      {:card-list/cards (get-card-ids-from-note crux {:note/id id})}})
2021-09-03T16:31:15.591Z xps INFO [sheluchin.parser:37] - Process [{[:note/id 1] [#:note{:card-list [:card-list/id]}]}]
2021-09-03T16:31:15.593Z xps DEBUG [sheluchin.resolvers:88] - note-id->card-list-id-resolver #:note{:id 1}

2021-09-03T16:34:50.814Z xps INFO [sheluchin.parser:37] - Process [{[:note/id 1] [#:note{:card-list [:card-list/id]}]}]
2021-09-03T16:34:50.816Z xps DEBUG [sheluchin.resolvers:97] - note-cards-resolver#:note{:id 1}
#:note {:card-list #:card-list {:cards (get-card-ids-from-note crux #:note {:id id})}}
=> #:note {:card-list #:card-list {:cards [#:card {:id 1}]}}
Can anyone help me understand what's happening here? It looks to me like I'm ultimately requesting :card-list/id that's related to a :note/id. A note looks like this:
{:note/id 1 
 :note/card-list {:card-list/id 2}}


Pathom doesn't take the nested output in consideration, for pathom you just have 2 options for :note/card-list


@U0VP19K6K is doing some work to make this be a consideration in Pathom 3


but Pathom 2 awareness of nested things like this is more limited


@U066U8JQJ what is the recommended approach for dealing with this limitation? Should resolver output descriptions generally be flat/without nesting? Hmm... I see the docs explain that nested descriptions are still useful for autocomplete and automatic testing. I guess that means that nested output descriptions should be used, but that if the nested data needs to be exposed to the graph, those keys also need to be included as top-level keys in their own resolvers?


Silly question, is there a use case for using Pathom to query Datascript on the front-end for certain situations? Resolving on Datascript indexes directly? Reason I ask is I’m hitting a wall with some recursive queries in Datascript. I’m sure it’s something in the way I’m writing the query, but it got me wondering if Pathom would fit in this situation if there are deeply nested structures. Is there a big difference between EQL pull syntax in Pathom and Datascript?


the pull syntax for DataScript is different than Pathom


Would pathom make sense in this instance or am I misunderstanding Pathom?


pathom probably won't help you write faster datascript queries

👍 2

Pathom isn't going to be faster, but I have cases that I used resolvers to query on datascript, the advantage is that you can extend the system with things that are not in datascript, its a bit more advanced, but using dynamic resolvers you can make pathom aware of what to delegate down to datascript


the closest example to that is the datomic integration for Pathom 3


Thank you @U066U8JQJ sounds great.


I think a library that implemented EQL on top of datascript would be p cool

henrik21:09:29 implements EQL-style pull, and harmonizes quite well with Pathom.


Oh this looks fantastic. Thank you @U06B8J0AJ @U4YGF4NGM

👍 2

yeah, it's not going to interop with datascript, but if you're willing to replace datascript - it's a pretty good solution 🙂


i'm secretly working on a datalog impl for it, but it probably won't ever have complete parity with datascript's features

💪 2

That’s exciting