Fork me on GitHub
Mr. Savy21:12:28

i've been trying to recreate the pagination example from the book without much success. :page/items still evals to an empty collection after doing a transaction, so I've been looking at the query being passed through the network to try to understand what's going on. I don't think I understand how this query is being evaluated. where is it being received?


Query looks fine. You’d need a resolver on server that can respond to that.

(defresolver paged-items [env input]
  {::pc/output [{:paginate/items [:item/id]}]}
  (let [params (-> env :ast :params)] {:paginate/items [{:item/id 1} ...}]}))

Mr. Savy21:12:26

ok nice, it's reassuring to know my initial suspicion was right. For testing purposes, I was using the same resolver the book uses, which just about matches that one. However from what I can tell it never hits the resolver, but I'm not sure why. I read the main section in the book on resolvers, but I never saw anything that explained how the resolver receives the transactions. Does fulcro just add each created resolver to a list to check transaction against, or is there something else I need to do aside from just defining the resolver?


You need to register it with pathom.

🎉 3
Mr. Savy22:12:51

that did it, thank you both! I apologize for my ignorance. thankfully, the fulcro template has its own middleware set up with its own resolvers, so adding the new one to the def that exists in the pathom file allowed it to be registered with the rest and pick up the transaction. so as I now understand it, you have to create a def holding all your resolvers and then register that with the pathom parser plugin? this looks like it matches what's in section 4.12, so I'm going to spend some time comparing this section with the template.


That's correct. 👍


Under if you follow "Query does not return the expected data" - "Is there a resolver for the property/join in question" you will get to "If missing: have you created the resolver? Have you registered it with Pathom" and info how to chech / troubleshoot it

👍 3
Mr. Savy23:12:44

thank you! when I initially thought it was a frontend/query design issue I did refer to your guide (in particular, the "`load!` from the server" section). now that I am starting to get exposure with resolvers this will be a good section to read through as well. if I had only known it was a resolver issue sooner, I may have thought to go over that section! facepalm


Well, you knew the problem was that your query did not return the data you expected.... 🙂


Is it normal that :initLocalState gets never updated on reload once it has been added? Full page refresh is necessary.


I guess it is only called when the component is mounted so this behavior wouldn't surprise me. Though not sure what you mean by "reload". Reload button in the browser?


:initLocalState is tied to the react component's lifecycle, isn't it? so it should get called every time your component is mounted, which could happen more than once for a single page render but might not necessarily


Pure react. It's part of the generated constructor


So mount/unmount


@U0522TWDA Hot reloading by shadow-cljs Yes but :initLocalState does not seem to be updated even for newly mounted components (after the hot reload), and that is the part I find weird. Since they are newly mounted, they should call the newly reloaded ctor code, shouldn't they?


Are you 100% sure that hot reload did remount them? Perhaps add the on Component Mounted hook and log from there?


I am 100% sure that :initLocalState is never updated once it has been set once. That is, after modifying :initLocalState, even new components (which are mounted only after hot reload) do not execute the new code. I have to refresh the page myself.


well, then that would be a bug @UCFG3SDFV. Perhaps a regression? I’ve used that feature and do not remember such misbehavior, but perhaps I was using it in a circumstance where it didn’t matter


@U0CKQ19AQ Sorry for the delay, I was in a rush. So, I was thinking that it was perhaps somehow because of my shadow-cljs config, since no one else was reporting this "obvious" behavior. But after tweaking a few things, the problem remains. It is not a mere regression since this is was I have always known, even in earlier versions. I guess I must be doing something wrong. However, it is really weird that only :initLocalState misbehave and absolutely nothing else.


Open an issue. Sounds like you can reproduce the issue. Should be easy to fix (I hope)