This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-05
Channels
- # 100-days-of-code (1)
- # announcements (7)
- # beginners (84)
- # boot (1)
- # cider (22)
- # cljdoc (14)
- # cljs-dev (45)
- # cljsrn (6)
- # clojure (65)
- # clojure-conj (7)
- # clojure-finland (1)
- # clojure-italy (7)
- # clojure-nl (2)
- # clojure-serbia (1)
- # clojure-uk (111)
- # clojurescript (58)
- # cursive (8)
- # datomic (68)
- # duct (1)
- # emacs (33)
- # figwheel (3)
- # figwheel-main (9)
- # fulcro (33)
- # graphql (1)
- # juxt (30)
- # kaocha (4)
- # off-topic (22)
- # pathom (47)
- # pedestal (4)
- # planck (6)
- # re-frame (1)
- # reagent (1)
- # reitit (13)
- # shadow-cljs (49)
- # spacemacs (7)
- # sql (6)
- # tools-deps (60)
@wilkerlucio is there any way to get the parsers to work with idents that don’t fit the classical pathom ident style? For example, I want to do a
(df/load reconciler [:foo/by-id 0] Foo {})
I am aware of open-ident-reader
, but it doesn’t seem to do the trick. I’m trying to write my own fulcro-ident-reader, but i keep coming back to using prim/db->tree
within that reader. Not sure if what i’m doing is sane 😛about the ident, the thing is, the pathom design is made to remove the separation between what is data and what are entry points, the by-id
concept to me just looks like you are giving id
a second name, you can do it, I just dont see any gains, you add complexity by adding one unescessary name to your system, and adding effort to the engine to keep converting it
you can create resolvers that convert by-id
to id
and vice versa, so they get to be the same
@levitanong can you tell me more about why you are using db->tree? and in which point? you should never need it
@wilkerlucio I’m trying do (df/load reconciler [:foo/by-id 0] Foo {})
. I initially built a reader that looked something like:
(defn fulcro-ident-reader
[{:keys [ast state] :as env}]
(let [{:keys [key component]} ast
state-map @state
extra-content (get-in ast [:params :pathom/context])
entity (get-in state-map key)]
(if (vector? key)
(let [entity-with-extra (merge entity extra-content)]
;; Problem is, sometimes entity has this shape:
;; {:foo/id 0 :foo/bar [:bar/by-id 1]}
;; and I get an error in the value complaining about the value of`:foo/bar`
;; not being a sequence. I'm guessing it's trying to access the ident as a map
(p/join (atom entity-with-extra) env))
::p/continue)))
with connect you shouldn't need to write any new readers, also the context is also a bit of advanced feature, I wonder why you are hitting those already
oh i just added the context thing because i looked at the source of open-ident-reader
in Connect its all about attributes, right, so when you do a query like [{[:foo/by-id 123] [:foo/bar]}]
and i think it’s useful to separate the table name (like foo/by-id
) from the identifying attribute (`foo/id`) because sometimes identifying a component is more complicated than just getting one property
what you are doing is providing the data {:foo/by-id 123}
not really, identity is about a way to look the thing up, id
is one option, but you can use any sort of thing, even new names
my problem is just having multiple names for the same thing (`id` and by-id
), but you can still use those, but you have to write some resolvers to normalize it
for example
(pc/defresolver foo-by-id->id [_ {:foo/keys [by-id]}]
{::pc/input #{:foo/by-id}
::pc/output [:foo/id]}
{:foo/id by-id})
(pc/defresolver foo-id->by-id [_ {:foo/keys [id]}]
{::pc/input #{:foo/id}
::pc/output [:foo/by-id]}
{:foo/by-id id})
adding those you made :foo/id
and :foo/by-id
effectively equivalent
ooooh, that’s pretty cool
didn’t think you could do it that way
but I still suggest you avoid it, its just extra work for the parser 😛
it would take a lot of tedious work to move away from the /by-id
convention 😛
i’ll let the parser do the extra work for now 😛
ok, hehe
in pathom is all about attributes
and you should be free to mess with then (translatre, join,separate...)
before the parallel that thing above that I typed could result in bad loops, but the new implementation is smarter, doest fall there 😉
awesome!
i suppose i’d have to keep pc/open-ident-reader
for it to accept [:foo/by-id 0]
since :foo/by-id
wouldn’t be in the index
correct
actually, no
or… would the new defresolvers add those?
yeah they would
so it would just have to be pc/ident-reader
yeah, idents are generated when any resolver is added and it has a single input
but I personally prefer the open-ident-reader
myself
because there are cases where I want to load something and the ident just doesn't matter (singleton cases)
so the open-ident-reader still useful on those cases
the only reason to use the ident-reader
is that if you wanna have extra ident readers in your system doing something else, so the ident-reader
will forward the process when the ident is unknown
oh, because it’ll just ::p/continue
correct
would there be any case for having both?
i assume that since it’s middleware-based, there is an order at which they are applied
so you could have open-ident-reader as a catchall
right?
yeah, that's possible
another thing to keep in mind is about each reader performance
map-reader
is quite fast, so it goes first (also because of caching and entity things), so always remember that to reach some reader far away, the ones before it must run, they are usually fast enough and good readers should short-circuit as soon as possible
this is more a thing to keep in mind if you are writing readers, but these days connect handles the great majority of things, so custom readers should not be so common
got it