This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-09-03
Channels
- # announcements (3)
- # asami (4)
- # aws (1)
- # babashka (22)
- # beginners (111)
- # calva (3)
- # cider (1)
- # clj-kondo (55)
- # clj-on-windows (9)
- # cljsrn (1)
- # clojure (13)
- # clojure-europe (35)
- # clojure-losangeles (3)
- # clojure-nl (2)
- # clojure-norway (2)
- # clojure-spec (2)
- # clojure-uk (5)
- # clojurescript (51)
- # conjure (5)
- # cursive (5)
- # datascript (1)
- # datomic (27)
- # deps-new (8)
- # depstar (41)
- # emacs (4)
- # fulcro (24)
- # graphql (4)
- # gratitude (8)
- # helix (36)
- # jobs (2)
- # leiningen (2)
- # lsp (11)
- # off-topic (24)
- # pathom (23)
- # pedestal (2)
- # polylith (27)
- # re-frame (12)
- # reagent (7)
- # reitit (1)
- # releases (3)
- # remote-jobs (1)
- # rewrite-clj (4)
- # sci (1)
- # shadow-cljs (27)
- # spacemacs (12)
- # tools-deps (31)
- # web-security (2)
hello, glad to announce a few new documentation pages on Pathom 3! • https://pathom3.wsscode.com/docs/foreign • https://pathom3.wsscode.com/docs/dynamic-resolvers • https://pathom3.wsscode.com/docs/integrations/graphql • https://pathom3.wsscode.com/docs/tutorials/graphql-integration This is the beginnings of the https://www.youtube.com/watch?v=IS3i3DTUnAI vision landing on Pathom 3!
I'm confused why a note-cards-resolver
is being called when it doesn't promise the desired fields in ::pc/output
:
(api-parser
[{[: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})
{:note/card-list
{: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}
#p[sheluchin.resolvers/note-cards-resolver:92]
#: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 thank you
@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?
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.
https://github.com/lilactown/autonormal implements EQL-style pull, and harmonizes quite well with Pathom.
yeah, it's not going to interop with datascript, but if you're willing to replace datascript - it's a pretty good solution 🙂