Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2021-08-23

Channels

#fulcro
<
2021-08-23
>
Hukka10:08:00

Not sure if this is a fulcro or pathom thing. I am going through the exercises by @holyjak and am now integrating the Pathom. In the EQL browser it seems like the autocomplete works only half way, even after loading the indices, and even when the query works. More concretely 

[{[:player/id 1]
  [{:player/address [:address/city]}]}]
works, but the autocompletion in the innermost part (the city) autocompletes on a global scope (so to the pathom internal stuff and the :teams

Jakub Holý (HolyJak)10:08:49

The problem is that Pathom does not know what :player/address is, it is opaque to it. It has been only told that it exists but that what the value is, i.e. that the value has :address/id etc. Let me see at how to fix it.

Jakub Holý (HolyJak)11:08:04

So the solution is to update defresolver player - ::pc/output by replacing :player/address with {:player/address [:address/id]}. Thus Pathom knows that it can get from :player/address to :address/id and thus also to :address/city.

Hukka11:08:29

Ah, I see, yes. Makes sense that the autocomplete is controlled by the schema

Hukka11:08:55

Though perhaps surprising that queries still work, with disconnections in the schema graph

Hukka11:08:29

For the sake of the tutorial/exercise, would it make sense to have that connection already in the my-very-awesome-teams?

👍 2
Jakub Holý (HolyJak)11:08:59

Queries work because they look at the data, not about what the resolver declares it returns.

Hukka11:08:29

I think that it's perhaps an untrivial thing to realize, that is, it might be a step too far to leave it only in the solution, while the original template for the exercise has a disconnected graph. At least if there isn't a pointer that there's a bug, and the reader should look at the my-very-awesome-team resolver options to fix the autocomplete

Hukka11:08:11

Then again, I guess so far I was the only one who noticed and didn't know what was happening 🙂

Jakub Holý (HolyJak)12:08:57

good catch, I should have thought of that 🙂

sheluchin20:08:27

In https://book.fulcrologic.com/#_parsing_queries, there is an example of a resolver: 

;; Given a :list/id, this can generate a list label and the people
;; in that list (but just with their IDs)
(pc/defresolver list-resolver [env {:list/keys [id]}]
  {::pc/input  #{:list/id}
   ::pc/output [:list/label {:list/people [:person/id]}]}
  (when-let [list (get list-table id)]
    (assoc list
      :list/people (mapv (fn [id] {:person/id id}) (:list/people list)))))
Why does this resolver assoc in a vector of person ids using map forms like (`{:person/id id}`) instead of assoc'ing in a vector of idents? The way I think about it, idents should be used like a foreign key - just a pointer to more complete record elsewhere. But I notice that that ident-like maps are often used instead. Can anyone please explain?

Jakub Holý (HolyJak)21:08:56

Idents are used in the frontend ie Fulcro. The backend - Pathom - works with maps.

👍 3
Jakub Holý (HolyJak)21:08:44

Remember, Pathom returns a denormalized tree of data. F introduces idents to normalize it.