Fork me on GitHub
Björn Ebbinghaus11:02:06

@wilkerlucio Is there a way to add aliases for inputs? I have resolvers which output {:foo/id 42}, so :foo/id would be the input for the foo-resolver But I would also like to query with an ident [:foo/by-id 42] Or should I call the resolver, instead of returning {:foo/id 42} Would it be a good idea, that the first resolver returns [:foo/by-id 42] which will then always be resolved? I hope you understand what I am thinking. 🙂

Björn Ebbinghaus11:02:42

Something like this:

(pc/defresolver foo [_ {id :foo/by-id}]
  {::pc/input #{:foo/by-id}
   ::pc/output [:foo/id :foo/name]
  {:foo/id id :foo/name (str "Foo_" id}))

(pc/defresolver bars [_ _]
  {::pc/output [{:bars foo}]  <-- or like prim/get-query in fulcro
  {:bars [[:foo/by-id 1] [:foo/by-id 2]]}
such that
[{:bars [:foo/name]}]

Results in:
[{:bars [{:foo/name "Foo_1"}
         {:foo/name "Foo_2"}]}]


Might I recommend to change your idents to :foo/id. If you do that you could change your foo resolver to have #{:foo/id} as input. If you then change your bars resolver output to:

[{:bars [:foo/id]}]
And then if you return
{:bars [{:foo/id 1} {:foo/id 2}]}
Pathom will know how to resolve :foo/name

Björn Ebbinghaus12:02:44

But :foo/id is a field, I am worried that it is confusing if it could also be an index. 😕 What use are all these namespaced keywords, if I can not rely on what they are?


you can do

(pc/defresolver bars [_ _]
 {::pc/output [{:bars [:foo/id]}]
 {:bars [{:foo/id 1} {:foo/id 2}]}


@U4VT24ZM3 you can write a simple alias resolvers to convert one to the other (use (pc/alias-resolver2 :foo/id :foo/by-id)), but that said I suggest you just use the field name, its not problem at all, it makes simpler to understand (because in pathom anything can be made a connection, the idea of by-id been something special doesn't add much for you)

Björn Ebbinghaus12:02:52

But if [:foo/id 1] is the ident of {:foo/id 1} the resulting state would look like this: {:foo/id {1 {:foo/id 1}}} :foo/id denotes an index AND a field in an object in this index. Don't you think this is bad?


This is only in the fulcro local db, that has nothing to do with pathom?


{:foo/by-id {1 {:foo/id 1}}}


This is not such a huge deal to me, but you can choose to do either way, but we moved really fast to refactoring all by-id keywords to simple id keywords

Björn Ebbinghaus13:02:47

I understand, that it won't be a huge deal, but I am feeling somewhat guilty about that, you know?


Yeah I get it, but pathom sees it a bit different


It looks at it like this: If i have an id i can get the following props for you


And you can go further you can also say if the map contains a id and something-else I can resolve even more for you


So for you it says: if you have a foo/id I know how to get the foo/name


but you could also write if you have: foo/first-name and foo/last-name I can resolve foo/full-name for you


so basically [:foo/id 1] is only syntax which it changes to {:foo/id 1} and then feeds to the pathom resolver

Björn Ebbinghaus13:02:01

I understand that, but I think that the ident-reader distorts the meaning of an ident (at least in the sense of fulcro), by making this change from [:foo/id 1] to {:foo/id 1} It looks at the ident as a part of the object, not a "reference" to the object.


@U4VT24ZM3 the ident is what it means, and "identifier", if we look at other places that have similar features in the clojure world, one is the datomic lookup refs, they look exactly like idents, and they point direcly to some attribute to enable further lookup. I see this fulcro idents as the same, the reason of by-id is most historical, [:foo/id 1] starts makes sense if you think that the attribute is like a primary key, and in pathom terms anything can be a key to something else, IMO when you start thinking on that direction than the by-id stops making sense and start seems just like some unnecessary overhead. makes sense?

Björn Ebbinghaus14:02:18

To look at it like a primary key makes sense, indeed.


How can I print/capture the entity before it?

:cause "class clojure.lang.Keyword cannot be cast to class clojure.lang.IObj (clojure.lang.Keyword and clojure.lang.IObj are in unnamed module of loader 'app')"
 [{:type java.lang.ClassCastException
   :message "class clojure.lang.Keyword cannot be cast to class clojure.lang.IObj (clojure.lang.Keyword and clojure.lang.IObj are in unnamed module of loader 'app')"
   :at [clojure.core$with_meta__5405 invokeStatic "core.clj" 217]}]
 [[clojure.core$with_meta__5405 invokeStatic "core.clj" 217]
  [clojure.core$with_meta__5405 invoke "core.clj" 217]
  [com.wsscode.pathom.core$elide_items invokeStatic "core.cljc" 219]
  [com.wsscode.pathom.core$elide_items invoke "core.cljc" 216]


what you mean entity before it?


not sure what i need to capture/debug


I dont understand what you want, its a debugging thing?


I’m returning :fulcro.client.primitives/tempids from a pathom resolver but it is not being picked up by fulcro. I do see it in the response though :thinking_face:


@wilkerlucio is there something pathom is doing to munge the tempids from fulcro? I’m getting a different looking datastructure after applying a defmutation in the backend


Something like {:id #uuid "17ea4e29-41e8-4692-a521-825d87880fcb"} 5990139348123779}


what happens is that if you use some mutation response, only what your mutation response asked will be returned, and that can elide tempids, so global mutation joins is a feature to make that easier by always making it part of the output (when present)


oh, but you are seeing the value changing? it should not change, if thats the case I suggest you take a look at the transfer layer (transit or whatever you are using), some data might be get compromised there (a common issue is not setting up fulcro tmpids with the transit, on the client or on the server)


How do I do that? (set up fulcro tempids in transit)


@wilkerlucio it appears that I needed some tweaking of my transit response function. However, the data I receive in that function does not have the temp ids correctly. Can pathom be changing the tempids?


no, pathom doesn't touch your data in any way, unless you hit some weird bug, but I have not see it happening so far


you need to check if the data is getting proper encoding, try logging at different places and see where its changing


Currently I’m logging in the resolver before sending off the data


you can do in the result of the parser call itself


because that's the last before encoding out (in most cases), so you can make sure there if there is any changing ocurring after you return it


I’m looking at

                         ;; this map is `env`. Put other defstate things in this map and they'll be
                         ;; added to the resolver/mutation env.
                         {:ring/request request}
                         (:transit-params request))]


but that call is already encoding it incorrectly


@wilkerlucio @tony.kay found the culprit (p/post-process-parser-plugin p/elide-not-found)


That pathom plugin was encoding tempids incorrectly


Once I removed it, everything worked


humm, thats strange but a good catch, can you open an issue so I remember to debug it later?


@pvillegas12 I just got able to reproduce it in a consistent way, the issue is that (map? (fp/tempid)) returns true (which seems very weird to me), so the p/elide-not-found os navigating down on it


@pvillegas12 this version should fix the tempid issues with elide not found, @souenzzo this also bumps the keys to fix the issue you were having

👍 15