This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-13
Channels
- # aleph (16)
- # announcements (8)
- # aws (5)
- # babashka (54)
- # beginners (48)
- # calva (7)
- # cider (7)
- # clojure (209)
- # clojure-brasil (4)
- # clojure-europe (20)
- # clojure-italy (12)
- # clojure-nl (21)
- # clojure-uk (69)
- # clojurescript (24)
- # cursive (11)
- # datascript (7)
- # datomic (47)
- # emacs (14)
- # graphql (20)
- # hoplon (25)
- # jobs (1)
- # kaocha (1)
- # leiningen (14)
- # meander (7)
- # off-topic (44)
- # other-languages (1)
- # pathom (20)
- # re-frame (2)
- # reagent (51)
- # reitit (3)
- # remote-jobs (1)
- # shadow-cljs (46)
- # spacemacs (5)
- # sql (65)
- # tools-deps (86)
- # vim (11)
@alex.sheluchin for now you still need to set up parser like in walkable's documentation. Walkable was created before pathom connect. With the new dynamic resolver feature coming in pathom 2.3.0-alpha4, integration with pathom connect is possible - I'll try to make connect version of walkable soon, hopefully next week
@U0E2YV1UZ thank you. I think my use case is simple enough to stick with what's available, I was just trying to understand the correct pattern to use. I'll be looking forward to making use of the Connect support once that does come around.
I've got a case where :note/objects
can have :text-object/text
property or :tag-link/tag
property: :note/objects [:text-object/text :tag-link/tag]}
but with this syntax I am getting a lot of :com.wsscode.pathom.core/not-found
https://github.com/wilkerlucio/pathom/commit/fed5f103dcf5a63df270e02b05d0429e50595dad remove those with this plugin 🙂
alternatively if these represent different entities altogether, then use union queries: https://wilkerlucio.github.io/pathom/#_union_queries
::p/plugins [(pc/connect-plugin {::pc/register [(resolvers/resolvers)
(mutations/mutations)]})
p/elide-special-outputs-plugin
p/error-handler-plugin
]}))
Just like that, and this should get rid of any :com.wsscode.pathom.core/not-found
?
Are there any facilities to deal with complex EQL queries? When I need to ask for deeply nested, complex structure - it quickly becomes difficult to manage.
@slawek098 you make a queries namespace and you write functions that build your queries
(defn login
[{:user/keys [username email password]}]
{(list 'login (cond-> {:user/password password}
email (assoc :user/email email)
username (assoc :user/username username)))
[{:auth/tokens [:access-token
:expires-in
:offline-token
:id-token]}
{:auth/user [:user/id
:user/username
:user/name
:user/photo
(user-stuff {})]}
(search-things {:limit 3})]})