This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-12
Channels
- # adventofcode (2)
- # aleph (2)
- # announcements (5)
- # aws (5)
- # babashka (25)
- # beginners (167)
- # calva (8)
- # cider (1)
- # clj-kondo (3)
- # cljsrn (19)
- # clojure (87)
- # clojure-conj (7)
- # clojure-dev (19)
- # clojure-europe (1)
- # clojure-italy (14)
- # clojure-losangeles (1)
- # clojure-nl (4)
- # clojure-norway (3)
- # clojure-spec (18)
- # clojure-uk (29)
- # clojuredesign-podcast (3)
- # clojurescript (40)
- # clojurex (11)
- # core-async (13)
- # core-logic (2)
- # cursive (16)
- # data-science (4)
- # datascript (10)
- # datomic (53)
- # emacs (1)
- # events (15)
- # fulcro (71)
- # jobs (1)
- # jvm (2)
- # malli (4)
- # nrepl (2)
- # pathom (74)
- # re-frame (1)
- # reitit (19)
- # remote-jobs (1)
- # rewrite-clj (18)
- # ring (2)
- # shadow-cljs (132)
- # spacemacs (22)
- # tools-deps (65)
Hi there, I’m building a backend with pathom in CLJS. I’m following the Fulcro guide and I’m at the point where I’m playing with parsers in the REPL.
However, when I pull my parser namespace into the REPL and call api -parser
it gives me this error:
TypeError: Cannot read property 'ReadPort' of undefined
at $wsscode$common$async_cljs$chan_QMARK_ [as chan_QMARK_] (/Users/mruzekw/Code/serverlesstest/myapp/.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/com/wsscode/common/async_cljs.cljs:7:3)
TypeError: Cannot read property 'ReadPort' of undefined
at $wsscode$common$async_cljs$chan_QMARK_ [as chan_QMARK_] (/Users/mruzekw/Code/serverlesstest/myapp/.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/com/wsscode/common/async_cljs.cljs:7:3)
at com$wsscode$pathom$core$wrap_parser_exception_$_wrap_parser_exception_internal (/Users/mruzekw/Code/serverlesstest/myapp/.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/com/wsscode/pathom/core.cljc:830:7)
at /Users/mruzekw/Code/serverlesstest/myapp/.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/com/wsscode/pathom/connect.cljc:1695:13
at $wsscode$pathom$core$wrap_normalize_env_internal__3 [as cljs$core$IFn$_invoke$arity$3] (/Users/mruzekw/Code/serverlesstest/myapp/.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/com/wsscode/pathom/core.cljc:1009:7)
at $wsscode$pathom$core$wrap_normalize_env_internal__2 [as cljs$core$IFn$_invoke$arity$2] (/Users/mruzekw/Code/serverlesstest/myapp/.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/com/wsscode/pathom/core.cljc:1006:4)
at myapp$backend$parser$api_parser (/Users/mruzekw/Code/serverlesstest/myapp/.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/myapp/backend/parser.cljs:47:3)
at cljsEval (<eval>:1:41)
at global.SHADOW_NODE_EVAL ([stdin]:105:10)
at Object.shadow$cljs$devtools$client$node$node_eval [as node_eval] (/Users/mruzekw/Code/serverlesstest/myapp/.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/shadow/cljs/devtools/client/node.cljs:24:1)
at /Users/mruzekw/Code/serverlesstest/myapp/.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/shadow/cljs/devtools/client/node.cljs:49:13
looks like that you are mixing -async
things with non-async things . But I can't understand how.. You are using some p/async-parser
or pc/mutate-async
or some -async
reader?
The parser is defined as:
(def pathom-parser
(p/parser {::p/env {::p/reader [p/map-reader
pc/reader2
pc/ident-reader
pc/index-reader]
::pc/mutation-join-globals [:tempids]}
::p/mutate pc/mutate
::p/plugins [(pc/connect-plugin {::pc/register resolvers})
p/error-handler-plugin]}))
Fulcro by default assumes you are using the parallel parser, the parallel / async return channels, but the normal one doesn't, look for a place with <!!
and remove it, so it doesn't try to read from a map 🙂
that's my guess ,but let me know if its something different
how are you integrating this parser? this is a cljs parser, right?
(for cljs you probably want the async-parser, otherwise you wont be able to do anything async, like http requests)
ah, on lamba, ok, this way you may be ok with serial, hehe
how did you setup the fulcro remote for it?
can't reproduce. https://gist.github.com/souenzzo/58cf26321fc2ab91fde9dbcef9b3781a Should be something "external" (as fulcro wraper)
strange, can you post the full code of what you trying on a gist?
why do you have 2 parsers?
the parallel will return a channel
but I'm finding very strange that error you got
for read port
that's nothing much else going on around?
but also, that setup on the regular parser seems old
try this:
(def pathom-parser
(p/parser {::p/env {::p/reader [p/map-reader
pc/reader2
pc/open-ident-reader
p/env-placeholder-reader]}
::p/placeholder-prefixes #{">"}
::p/mutate pc/mutate
::p/plugins [(pc/connect-plugin {::pc/register resolvers})
p/error-handler-plugin
p/trace-plugin]}))
one detail, on your parallel. you were using a wrong variable on the resolvers
also, you don't need double list here: (def resolvers [[person-resolver list-resolver]])
it gets flatten, the reason to support vectors is jjust to make composition easy
but in pratice its a flat list
So p/parser
is just a sync parser and should just return the result, right? No channel needed?
that's what is bugging me, makes no sense 😛
so, I wrote a small demo for you: https://github.com/wilkerlucio/pathom-cljs-demo
this repository is working, you can clone and run shadow-cljs watch app
it logs a parser result to the console
I hope you may find a difference with your setup
console here
it should be the same
I’m not sure if my shadow-cljs compiler was watching for changes. Thus the code you originally gave me probably worked, but wasn’t loaded when I reloaded the ns in the REPL
you should check if that behavior was expected at #shadow-cljs
@mruzekw to me, when comparing Pathom with GraphQL, the main difference is on the modeling, GraphQL uses a strict type schema, were types must defined ahead of time, while pathom embraces a very flexible property based modeling, where the central pieces are the properties, not the entities. this has a bunch of implications down the road, one example is when you try to combine multiple graphs, in the GraphQL case, its a pain in the ass, because you can't extend any of the types, also, because of the lack of namespaces, there is a good change you end up with conflicting types, they have workarounds, but IMO they fail to address the main issue here, that is, you need some way to talk about information that's not ambiguous.
in this sense, pathom things more like RDF, and encourage the use of long names (eg: :youtube.video/id
instead of :id
), those names enable multiple systems to live in the same space, this also enables that you make connections around those names. this way pathom makes easier to combine different graphs, in my work, our system deals with tons of REST endpoints, plus 2 different GraphQL sources, and you can get data from all of them in a single query, I find this property beautiful 🙂
and the trick for the GraphQL was simple, we just prefix all the names imported, so they wont collide
and when you have the base on properties, you can have style of resolvers you are seeing in Connect, that effectivelly kills the need for a controler, the index can do the composition for you
does some of that makes sense to you?