Fork me on GitHub
#pathom
<
2018-11-05
>
levitanong08:11:51

@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 😛

wilkerlucio10:11:23

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

wilkerlucio10:11:48

you can create resolvers that convert by-id to id and vice versa, so they get to be the same

wilkerlucio11:11:40

@levitanong can you tell me more about why you are using db->tree? and in which point? you should never need it

levitanong12:11:04

@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)))

wilkerlucio12:11:59

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

levitanong12:11:22

oh i just added the context thing because i looked at the source of open-ident-reader

wilkerlucio12:11:17

in Connect its all about attributes, right, so when you do a query like [{[:foo/by-id 123] [:foo/bar]}]

levitanong12:11:18

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

wilkerlucio12:11:51

what you are doing is providing the data {:foo/by-id 123}

wilkerlucio12:11:17

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

wilkerlucio12:11:42

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

wilkerlucio12:11:51

(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})

wilkerlucio12:11:16

adding those you made :foo/id and :foo/by-id effectively equivalent

levitanong12:11:31

ooooh, that’s pretty cool

levitanong12:11:35

didn’t think you could do it that way

wilkerlucio12:11:38

but I still suggest you avoid it, its just extra work for the parser 😛

levitanong12:11:28

it would take a lot of tedious work to move away from the /by-id convention 😛

levitanong12:11:38

i’ll let the parser do the extra work for now 😛

wilkerlucio12:11:53

in pathom is all about attributes

wilkerlucio12:11:04

and you should be free to mess with then (translatre, join,separate...)

wilkerlucio12:11:48

before the parallel that thing above that I typed could result in bad loops, but the new implementation is smarter, doest fall there 😉

levitanong12:11:51

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

levitanong12:11:07

or… would the new defresolvers add those?

levitanong12:11:10

yeah they would

levitanong12:11:17

so it would just have to be pc/ident-reader

wilkerlucio12:11:24

yeah, idents are generated when any resolver is added and it has a single input

wilkerlucio12:11:38

but I personally prefer the open-ident-reader myself

wilkerlucio12:11:50

because there are cases where I want to load something and the ident just doesn't matter (singleton cases)

wilkerlucio12:11:59

so the open-ident-reader still useful on those cases

wilkerlucio12:11:44

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

levitanong12:11:01

oh, because it’ll just ::p/continue

levitanong12:11:23

would there be any case for having both?

levitanong12:11:34

i assume that since it’s middleware-based, there is an order at which they are applied

levitanong12:11:43

so you could have open-ident-reader as a catchall

wilkerlucio12:11:52

yeah, that's possible

wilkerlucio12:11:22

another thing to keep in mind is about each reader performance

wilkerlucio12:11:10

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

wilkerlucio12:11:18

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