Wonderful work, @U0522TWDA! 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, @U0CKQ19AQ!), navigating to the relevant areas of the resolvers, etc. Anything that shows how all the small pieces comprise the whole is incredibly illuminating.

Thank you!

My 2 cents on this. You're totally right; I was heavily in a rush when starting out with fulcro, so I skimmed the docs, cloned RAD and started coding. That obviously didn't work out well, so I finally took the time to watch your YT series multiple times and read the book. The book and videos are highly complementary to each other, but what I underestimated the most was the amount of information in the podcast series you did. There's a lot of background info in there and I also appreciate that you explained a lot of your reasoning behind fulcro and its internals. I also started a similar collection of notes to @U0522TWDA (in german right now though). Simple stuff like "This exception is caused by that" + example code. Also, some rookie thoughts and aha moments. So I guess what I want to say is, you're right about people being in a rush, but most of all thank you for all the materials and fulcro of course! Oh and as you said multiple times, just cloning the entire fulcro source and looking things up was key to figure things out for me

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.

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

Sorr,y I am not sure I manage to follow your thinking. Thus I am not able to provide a good answer. You either define an all-in-one resolver like this

(pc/defresolver all-ents [env _]
  {::pc/input  #{}
   ::pc/output [{:all-ents [:ent-id :ent/a :ent/b :ent/c]}]}
  {:all-ents [{:ent-id "id" :ent/a 1, :ent/b 2, :ent/c 3} #_...]})

(pc/defresolver all-ents [env _]
  {::pc/input  #{}
   ::pc/output [{:all-ents [:ent/id]}]}
  {:all-ents [{:ent/id "id1"} {:ent/id "id2"} #_...]})

(pc/defresolver ent-id [env inputs]
  {::pc/input  #{:ent/id}
   ::pc/output [:ent/a :ent/b :ent/c]
   ::pc/transform pc/transform-batch-resolver}
  (mapv
    (fn [{id :ent/id}] {:ent/id id :ent/a 1, :ent/b 2, :ent/c 3})
    inputs))

(pc/defresolver all-ents [env _] ..)
(defattr id :ent/id :string
  {ao/identity? true
   ao/schema    :production})
(defattr a :ent/a :int
  {ao/identities #{:ent/id}
   ao/schema    :production})
(defattr b :ent/b :int ...)
(defattr c :ent/c :int ...)

> 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? Yes, provided you have defined components with correct idents, i.e. the query is something like [{:ent/all-ents (comp/get-query Entity)}] where Entity has :ident :ent/id . Given that and having loaded the data above, you will get :entity/id "table" in the client DB and be able to resolve any request for a particular entity from there. Of course if you manually issue (df/load! app [:entity/id 123] Entity) then this would require a resolver able to resolve it. But if you never issue a load like that, you are good.

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)

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!"))))})

You can do either. I would do the ent/id to all props, or let RAD auto-generate it from the attributes.

Notice the resolver can be smart, look at the actual query and only select the attributes requested from the DB. In pseudo code: (str "select " (map column-name (-> env :query)) " from someTable")

Moving the demos repo under the name FulcroDemos . Intent is to have 2 primary branches - first for all workspaces (demo state, form state, merge, etc.), and second a string of branches [tags?] progressively building up a full app with a remote as simply as possible. LMK if you can think of a better name. I plan to dump a bunch of my initial example code into the repo and write a blog post referencing it.