Fork me on GitHub

Hi @tony.kay, do you have any hints what I am doing wrong, when will-enter gets called thrice per one route-to? I am just now realising that this is not normal ;-)

Tyler Nisonoff16:04:27

check out the warning at the bottom of this section:

Tyler Nisonoff16:04:37

will-enter can be called multiple times as part of the route resolution algorithm and MUST NOT side-effect. Any I/O must be done in the lambda passed to route-deferred, which must then trigger the dr/target-ready mutation to indicate that the route is ready. You can use plain transact! to start a mutation within route-deferred, and the mutation can use target-ready! to send the signal.

❤️ 1

Thank you @U016TR1B18E! I just misread a paragraph of the book today, got confused and thought I did something stupid the last two years. Thanks!

Tyler Nisonoff16:04:19

yeah its quite subtle, glad it was helpful!


Where is the idiomatic place to put a mutation that goes with route-immediate?


The two are not compatible. Mutations are async by default, and you’d need to use route-deferred.


You could try using a synchronous transaction instead.


Otherwise, write a mutation that does the operation you want before routing, and have that mutation call the routing function. Then you’ll be sure the state has changed before the route appears.


There are all sorts of ways of structuring this…for example, you could invent your own pre-routing handler with the following scheme: 1. Add an option to the target like :custom/pre-routing (fn [app]) or whatever signature suits you 2. Write a wrapper function for routing that takes the target..e.g. (custom/route-to! this Target) 3. In this custom function, you can pull the pre-routing handler, and invoke it

(let [{:custom/keys [pre-routing]} (comp/component/options target)]
  (when pre-routing (pre-routing ...))
  (dr/change-route ...))
See RAD’s routing helpers for other ideas as well.


That last one should be your starting point for such an implementation.

thanks2 1

Works like a charm! Thank you @tony.kay!!!


I used componentDidMount so far, but that bites me when the old route and the new route only differ in the id part of [:person/id id].


In that case componentDidMount will not get called so the mutation will not fire.


I do not want to switch this use case to route deferred because route-immediate gives me a much smoother transition from the old route to the new (and when I do use route deferred in case the data is not yet loaded).


Smooth as in UI visuel smooth.


Hi there. I'm having some problem issuing a df/load-field! with :params, that is the params are not retrievable via (-> env :ast :params :foo). I've asked this question in #pathom and was told it's because Pathom is expecting the params to be somewhere else. For context, here's the thread:


For now the solution seems to be either writing a plugin to propagate the params downward, or to modify the query itself before sending it. I'm hoping someone could point me in the right direction to how to achieve these. Thank you 🙂


that’s a plugin that will take load params and move them into :query-params in pathom env for Pathom 2


@tony.kay It's working beautifully now. Thank you so much 😄

👍 1

@tony.kay, is there a reason for this conceptual difference between params at "entity level", vs "per attribute"? (glad to find the Pathom3 solution!)

Jakub Holý (HolyJak)16:04:38

This has come up multiple times lately. Perhaps it would be helpful to document it in the dev guide and/or move the plugging from RAD into Fulcro proper?


Parameters in the elements of the query would require constant use of dynamic queries in Fulcro, which I’ve always found to be a pain. You can do that, though, and EQL already supports carrying them in the right place and pulling them out at the resolver layer. IMO, though, namespaced parameters on the top-level query are sufficient for the vast majority of cases, are simpler to use, and can easily be pulled out into the pathom env. So, I use them way more…in fact, pretty much exclusively. I could (and have) gone on at length about the design of the loading infra in Fulcro…see videos/book/etc.


Thank you, "would require constant use of dynamic queries in Fulcro" clicks it for me.