This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-02-21
Channels
- # announcements (4)
- # architecture (161)
- # autochrome-github (7)
- # babashka (61)
- # beginners (42)
- # calva (24)
- # cider (22)
- # clj-kondo (28)
- # cljs-dev (8)
- # clojure (88)
- # clojure-art (2)
- # clojure-dev (7)
- # clojure-europe (43)
- # clojure-germany (2)
- # clojure-nl (2)
- # clojure-uk (4)
- # clojurescript (32)
- # core-async (41)
- # cursive (32)
- # datahike (6)
- # datomic (9)
- # emacs (22)
- # events (2)
- # fulcro (10)
- # graphql (1)
- # nextjournal (16)
- # off-topic (9)
- # overtone (1)
- # pathom (16)
- # polylith (5)
- # quil (7)
- # rdf (1)
- # re-frame (7)
- # reagent (22)
- # releases (2)
- # remote-jobs (1)
- # reveal (12)
- # sci (1)
- # shadow-cljs (12)
- # specter (20)
- # sql (6)
- # tools-deps (21)
- # vim (26)
- # xtdb (10)
How do you do the GraphQL ... on Type
thing in EQL? Trying to translate this query for Pathom:
{
repository(name: "pathom3", owner: "wilkerlucio") {
object(oid: "8e0a0453189bc13d045944d128248d0f2e7c5c17") {
id
commitUrl
... on Commit {
committedDate
}
}
}
}
just ask for the attribute (in this case would be something like :ns.Commit/commitedDate
, Pathom adds the ... on
part automatically
this is an advantage of knowing the full context of any attribute every time 🙂
let me know if you find any issues with it
Is there anything built in or a suggested approach for handling GraphQL pagination? Similar approach as in the https://pathom3.wsscode.com/docs/tutorials/hacker-news-scraper/#traversing-pagination?
Pulling out values from a GraphQL result with much nesting seems like a lot of work. Example:
[{:github.Organization/login login}
['({:github.Organization/repositories
[:github.RepositoryConnection/totalCount
{:github.RepositoryConnection/edges
[{:github.RepositoryEdge/node
[:github.Repository/id
:github.Repository/name
{:github.Repository/issues
[:github.IssueConnection/totalCount]}
{:github.Repository/pullRequests
[:github.PullRequestConnection/totalCount]}
{:github.Repository/defaultBranchRef
[:github.Ref/name
{:github.Ref/target
[{:github.Commit/history
[:github.CommitHistoryConnection/totalCount]}]}]}]}]}]}
{:first 2})]])
Result:
{:github.Organization/repositories {:github.RepositoryConnection/totalCount 29
:github.RepositoryConnection/edges [{:github.RepositoryEdge/node {:github.Repository/id "MDEwOlJlcG9zaXRvcnk5NzAzMjE1OA=="
:github.Repository/name "fulcro"
:github.Repository/issues {:github.IssueConnection/totalCount 270}
:github.Repository/pullRequests {:github.PullRequestConnection/totalCount 233}
:github.Repository/defaultBranchRef {:github.Ref/name "develop"
:github.Ref/target {:github.Commit/history {:github.CommitHistoryConnection/totalCount 4436}}}}}
{:github.RepositoryEdge/node {:github.Repository/id "MDEwOlJlcG9zaXRvcnk5NzAzNjU0Nw=="
:github.Repository/name "fulcro-spec"
:github.Repository/issues {:github.IssueConnection/totalCount 16}
:github.Repository/pullRequests {:github.PullRequestConnection/totalCount 7}
:github.Repository/defaultBranchRef {:github.Ref/name "develop"
:github.Ref/target {:github.Commit/history {:github.CommitHistoryConnection/totalCount 709}}}}}]}}
Is there any sugar for making life easier here? I was thinking of using https://github.com/escherize/tracks as a helper.Maybe you could add a resolver, that connects ˋrepositoriesˋ directly to the repository? Input repositories, output repository id Then you could skip edges and node
this is more about GraphQL design for pagination, which adds these extra steps, like @U4VT24ZM3 said, you may be able to shortcut by writing resolvers that simplify the request. At this point I think we need to verify if we can properly forward the params in this situation
I think this falls in the same domain as this issue, but instead of forwarding sub-queries parts, we may want something to point how to forward params: https://github.com/wilkerlucio/pathom3/issues/84
Thanks for the input. A shortcut resolver seems like it makes the most sense right now, but it does feel like there is potential for a shorter description.
I'm not sure I understand the shortcut resolver approach.
Is the idea that I should:
• create a resolver that takes :gh.Organization/repositories
• have that resolver do the work requesting additional levels down (edges and nodes, down to :Repository/id
), and flattening and return the results
Could someone please elaborate or link me to some source or documentation with a relevant example?