You can dr/change-route! to the the current route and :will-enter will be called again.

No, it does not

Yes it will, I can see the behavior.

Now if you are doing your load in dr/route-deferred in your :will-enter - that won't be called again because it's the same route

Maybe that is what you are observing?

Hmm... are you sure? A quick test shows that routing to the same path does not trigger :will-enter

But yes, ultimately I wanted to trigger dr/route-deferred

I may be misunderstanding - but I literally just put a put a println at the top of one of my :will-enter functions. Then I routed to it from the repl and saw the the effect. Are you logging (or doing something you can observe) outside of the dr/route-deferred?

What fulcro version are you using?

Could be an optimization added recently

3.5.22 - maybe it's affected by choice of renderer or some other config

My test is exactly the same.

Ok - well, maybe some better expert than me can chime in. But I can say with 100% certainty in my project, when I route to a target, the will enter is called. route-deferred from that method will return :already-there and bypass the deferred acton/

Ok, my bad. It's because I have a thin wrapper over my dr/change-route using pushy.

It turns out pushy does not trigger on-navigate when it's the same route

However, dr/route-deferred is still not called

I'll modify my question

I also tested a bit more and it looks like route-relative doesn't call the will-enter again on the parent routes (just the relative stuff)

Yes, that's my understanding -- the routing request is first converted to relative movements and then only those in the path will be affected.

To answer this part, what I do is put my load in a mutation. I transact the load from dr/route-deferred (along with the route ready after load. When I want the data re-loaded, I call that mutation. In some parts of the app, that's on a setInterval created in componentDidMount . I have a few spots where I really have to jump through hoops to get my data loaded and what I really want is just a pure React useEffect , but I haven't yet had the time to convert any of them to fulcro's hook support so I can't say how well that works.

Thanks for sharing. How does your log in component know which view to load then? Since each view has a different mutation in your strategy.

Or if you don't have that kind of log in behavior. How about implementing a refresh button that always refreshes the current view?

So, I generally wrap more complex behavior in a UISM. That way you can trigger events against that machine to do the various tasks based on what happens in the UI (route change, user interaction, etc.). Plain mutations, as suggested, which trigger loads are also reasonable, but harder to keep organized when things get a bit more complicated. I have long-term intention of integrating statecharts into Fulcro, but just have not had the time. There really are not many sources of needing to reload: event-driven (mount, user interaction, time-based, websocket push). In this case you’re trying to re-route, but what is the true source event? I mean, what’s wrong with making a plain reusable function that you call from routing and the place where you’ve decided you need a refresh?

No. I do tie I/O to rendering lifecycle and routing at times (for simple cases), but when you do that you always have to deal with the fact that routing and rendering are not very expressive, and lead to undesirable coupling of two or more competing concerns. This is why I suggest pulling the logic out into mutation helpers, mutations, functions, and UISM. Then you’ve got more general building blocks that can respond to those external events (routing, lifecycle, user events, timers, websocket push)

the (fn [] ...) solution does work for the query, and on a big query with lots of optional argument it's visibly faster, since there's much less data to receive and parse

optional attributes was my workaround to avoid the complexity of a union on a polymorphic entity, where my entity component queries for the optional attributes entity/type1, entity/type2... and the type specific attributes are requested by the type specific component query. a resolver returns for a given entity one of these type attributes with a nested id, and then each type has its own resolvers from typeX/id to whatever. pathom3 was unavoidable as it is much better at batching than pathom3. it does nested batches out of the box, and even batches entities of the same type together, so that to get the list of entities and their type specific attributes I end up with only 1 + number of types returned in the list queries instead of 1 + number of entities.

I guess the query checking fn would need to be updated to process (pco/? :real-attr-name) Do you want to give it a try?