Yeah, I don't understand it...
What if I don't have an ident? Like, I have the .../:username route, but the users are indexed by their ids and not usernames.
You pass a vector of strings to the route. It uses your route segments to turn that into the proper path parameters. This is all separate from idents and queries. It is pure data processing by the router with the intention of composition (of routers) and abstraction (not being tied to the idea of how routes are remembered (e.g. URL), navigated (back button), etc). Don’t conflate them. Dynamic routers are pure UI routers whose sole purpose is to get the right thing on the screen. For your convenience, the design is meant to be easy to use from a URL perspective (splitting a URL on / gives you the vector). The parameters to will-enter are purely from the vector and parameters you pass to change-route, and have nothing to do with the state db or query.
I didn't know about the route params, and haven't seen the route params mentioned in the book (and can only find them now in the legacy routers section), that's why I asked.
Hmm, I see. But how do I get the result of the router match into the component? Say the route-segment is [:username] (or ["user" :username]), how do I get the username into the component? Is issuing a load/mutation in route-deferred
the only way? There will be a delay then iiuc.
Make a mutation that puts it there and then changes the ui route.
No problem 😊
Not even in doc strings?
It is in the doc string, but didn't think to look there.
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?
Well, you knew the problem was that your query did not return the data you expected.... 🙂
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} ...}]}))
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?
Is it normal that :initLocalState
gets never updated on reload once it has been added? Full page refresh is necessary.
@holyjak 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 @adam678. 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
@tony.kay 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)
You need to register it with pathom.
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. 👍
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?
Under https://blog.jakubholy.net/2020/troubleshooting-fulcro/#_backend_pathom 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
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! 🤦