Clojurians Log v2

transact! doesn't need defresolver — transact! happens on the front end, it might have a remote section, then a request is sent to the remote. When the server handles the request, if it uses pathom connect, it will use the resolvers that allow it to answer the query.

https://book.fulcrologic.com/#_mutations_that_trigger_one_or_more_loads "The `df/load!` function simply runs a `transact!` on an internally-defined mutation with a special `:result-action`."

Maybe add this announcement in video description/comments?

It doesn't have to be a separate resolver with a unique name only for that load!: pathom connect will figure out a path to get the outputs you want from the inputs you provide, possibly through several resolvers.

So one resolver can have :user/username as input, :address/location-id as output, and another can have :address/location-id as input and :address/zip-code as output, if you send a query [{[:user/username "savy"] [:address/zip-code]}], pathom connect will figure out that it needs to run those two resolvers to respond to this query.

ok thank you! so it sounds like i'll need to make sure I have the appropriate resolver to handle the input and produce the right output

Hello! I have been told that some people were unsure how to apply troubleshooting steps recommended by my Fulcro Troubleshooting Decision Tree and were unsure about how to interpret the results. I have therefore added https://blog.jakubholy.net/2020/troubleshooting-fulcro/#_demo_of_a_troubleshooting_process with many screenshots and refer to it from everywhere in the guide where it is relevant. I would appreciate your feedback 🙏 Is it clear? Any improvements to make? ... For the curious, here is the diff https://github.com/holyjak/blog.jakubholy.net/commit/b12b5ac111da610b1a5e0f173443f977358334c7 Also, I am thinking about perhaps making ☝️ into a screencast but I am not sure whether the value added w.r.t. the existing text & pics justifies the effort. Thoughts?

I think it’s a nice improvement. beginners definitely need a lot more “look here” and “click on that”. The biggest problem I’ve seen with the screencasts is that a lot of people won’t take the time to watch them. They are in too much of a rush and don’t make the time. The written form allows them to be more efficient and quickly scan for something that looks “close” to the question they have at the moment. It’s why I do both. Some people will make the time to watch, and the videos can be really enlightening. Others will never watch and just want the quick scan of text for an approximate answer that they can immediately fiddle with.

I'm puzzled about how in practice resolvers for attributes stored remotely should be constructed so as to query the remote a reasonable number of times. I've gone through the documentation and the code in fulcro for automaticall generating resolvers for sql and datomic. I suspect I'm missing something simple. For now, suppose we are hand writing resolvers for simple entities/attributes [:ent/id :ent/a :ent/b :ent/c] to be read in from a remote data source. An EntsList component will be displaying all the ents with their attributes. So, along with the attributes above we define :ent/all-ents. In the RAD tutorial, the all-* queries only get ids from the remote, though I'm not sure why we wouldn't get it all at once, like this:

(defattr all-ents :ent/all-ents :ref
  {::pc/output  [{:ent/all-ents [:ent/id :ent/a :ent/b :ent/c]}]
   ::pc/resolve (fn [env _]
                  #?(:clj
                     (if-let [db (get-in env [:mydata/datasource :db])]
                       {:ent/all-ents (mydata/get-ents db)}
                       (log/error "Cannot find data source!"))))})

(defattr all-ents :ent/a :string
  {::pc/input #{:ent/id}
   ::pc/resolve (fn [env {:keys [ent/id]}]
                  #?(:clj
                     (if-let [db (get-in env [:mydata/datasource :db])]
                       {:ent/a (:a (mydata/get-ent-by-id db id))}
                       (log/error "Cannot find data source!"))))})
 

Wonderful work, @holyjak! I read the whole thing, and I found it incredibly instructive, and I think it wonderfully captures the process I’ve seen you go through. It is very clear, and describes very well the Fulcro machinery at work in a way I certainly would have found helpful — and I laughed at the resolution of the problem, as it’s something I’ve omitted by accident many times! IMHO, a short screencast would be helpful, as it shows not just the problem-solving discipline, but also how one uses Fulcro Inspector (which is incredible, @tony.kay!), navigating to the relevant areas of the resolvers, etc. Anything that shows how all the small pieces comprise the whole is incredibly illuminating.

P.S. For the case with the all-ents resolver above that gets everything at once, I suppose one could do

(pc/defresolver ents-resolver [env {:ent/keys [id all-ents]}]
  {::pc/input  #{:ent/all-ents :ent/id}
   ::pc/output [:ent/id :ent/c :ent/b :ent/c]}
  (some #(and (= id (:id %)) %) all-ents))

Thank you!

I think batch? true is indeed a good solution. Pathom is smart to leverage it automatically so if you query for [{:all-entities [:prop1 :prop2..]}] it will make 2 queries - 1 to fetch the ids, 1 to fetch all the "bodies". My all-* resolvers for SQL fetch the full data, not just idents. A system with separate resolver for ident lists and (batched) for ident -> props is simpler and more flexible. You can leverage the same ID -> some props resolver at a number of contexts instead of writing more complicated resolvers for each. It is your call to make, simplicity vs performance.

Not sure whether it is clear but Pathom is smart enough to find out which resolvers it has to call, ie it can combine a number of resolvers to answer a single query

Not sure what you mean by "resolver for ent/a". If you have an "all at once" all-ents resolver that returns all to props, not just idents, then you don't need it? Otherwise you will make something akin the auto-generated resolvers, taking :ent/id and returning all / the requested properties of the entity.

I think this doesn't make sense,at least to me. Just make a single #{:ent/id} -> [:ent/a...] resolver and make it batched. (Notice pathom has a helpful transform for that)

https://github.com/fulcro-community is alive! And awesome-fulcro has been moved there. Anyone who should be made a collaborator?

Thanks for the response. That's good to know about batch and the trade-offs between the ids only and the all at once. Regarding the resolver for ent/a, I had thought that pathom would choose for the resolver at the closest context so that it would be useful to be able to get smaller sets depending on whether all-ents was in the context. But I gather from what you said that if I have all-ents then it can figure out how to answer a query like [{[:ent/id id] [:ent/a]] automatically using all-ents. Is that right?

So to follow up, if the remote returns a data structure that looks like {:ent/all-ents [{:ent/id 1 :ent/a 1 :ent/b 1 :ent/c 1} {:ent/id 2 :ent/a 2 :ent/b 2 :ent/c 2} ...]} then that will be stored and normalized into the database automatically and any more specific query related to ents will use that client side automatically? So I need not define any other resolvers on the individual pieces because ents is read only. Do I have that right? Is the data structure properly formed in that case? If I do add a form, say, to write/update individual ents, do I then need additional resolvers or does it all still flow through all-ents?

Thanks again for your help

What transform is that? So if all-ents exists, will pathom draw from that (sequential case) and do queries otherwise (scalar case)? This is getting close to the center of my confusion. Thanks!

https://blog.wsscode.com/pathom/#resolver-batch-transform Not ure what all-ents is in this context. If, within the processing of a single query a resolver returns a sequence of idents (inside a map, of course) and the query needs some properties other than id from those entities and there is a resolver from id -> those props, it will be called for each ident. If it is batched, it will only be called once with all the IDs. See pathom docs about batching. If still unclear, you might get a. Better answer in #pathom

Thanks for your patience and sorry to belabor this, but what you just said hits on the one key question if you don't mind. The question is what the resolver(s?) for id -> other props looks like specifically in this context?? Suppose that I have the the following like you said:

(defattr all-ents :ent/all-ents :string
  {::pc/output [{:ent/all-ents [:ent/id]}]
   ::pc/resolve (fn [env _]
                  #?(:clj
                     (if-let [db (get-in env [:mydata/datasource :db])]
                       {:ent/all-ents (mydata/get-ent-ids db)}  ;; returns vector of ent/id's
                       (log/error "Cannot find data source!"))))})

(defattr a :ent/a :string
  {::pc/input #{:ent/id}
   ::pc/output [:end/id :ent/a]
   ::pc/batch? true
   ::pc/resolve (fn [env input]
                  #?(:clj
                     (if-let [db (get-in env [:mydata/datasource :db])]
                           (if (sequential? input)
                             (mydata/get-ents-in-id-set db (mapv :id input))
                             (mydata/get-ent-by-id db id)) 
                           (log/error "Cannot find data source!"))))})