doing df/load with query params worked out very will with your

query-params-to-env-plugin

on a side note // is there a script to upgrade to fulcro3 ? i thought you said while ago there was, but not sure if I remembered correctly

I started to write one, but it turned out to be a bit of work to automate well, and no one wanted to fund it…so…do it yourself via the doc: https://github.com/fulcrologic/fulcro/blob/develop/PORTING-FROM-2.x.adoc It really isn’t that hard. Mostly it’s adding this to react lifecycle methods and renaming things, which Replace In Path in IntelliJ does a nice job of.

hi, there! i’m wondering what is the suggested approach to do component load on route change in case of dr/route-immediate. docs say that :will-enter should be free of side-effects, so i see only 2 ways: to couple load with dr/change-route and to use :componentDidMount. both seem to be kinda problematic (the first is coupling, the second is semantically incorrect). there’s yet another way: to call dr/target-ready immediately (not as a post-mutation), but i recall you mentioned you’re not using dr/route-deferred that much, so i expect there’s a saner way

what’s wrong with route-deferred?

(defsc ReceiptTab [this {:keys [order]}]
  {:initial-state {}
   :ident         (fn [] [:COMPONENT/by-id ::receipt])
   :query         [{:order (prim/get-query receipt/OrderSummaryModal)}]
   :route-segment ["receipt" :order-id]
   :will-enter    (fn [app {:keys [order-id]}]
                    (let [id (uuid order-id)]
                      (dr/route-deferred [:COMPONENT/by-id ::receipt]
                        #(df/load app [:order/id id] receipt/OrderSummaryModal
                           {:post-mutation        `dr/target-ready
                            :marker               false
                            :target               [:COMPONENT/by-id ::receipt :order]
                            :post-mutation-params {:target [:COMPONENT/by-id ::receipt]}}))))}
  (receipt/ui-order-summary-modal order
    {:on-close #(uism/trigger! this ::om/orders-machine :event/to-detail)}))

i use it like that all the time

What he said ^^^^. Side-effect free means the side effects need to go inside the route-deferred return value, so that will-enter can be called any number of times while routers are trying to resolve the correct route based on the path. I’m starting to prefer using a UISM any time there is any complexity, since there is usually more than just “load this on route” in the overall application…so you solve that bit there and then still run into some other thing you want to do/keep track of, and it ends up scattered in the UI…UISM let’s you gather it into a coherent picture

yeah another big advantage of the UISM is it’s easy to trigger loads, show a loader, then route when you actually have the data

use route-deferred makes it a little difficult to show a loader why the data is being fetched

unless im missing something

@currentoor exactly last point: i want to navigate to the route asap and show the loader there. also, in case of deferred routing it’s more difficult to make it in sync with HTML5 routing (have to set the token after the load)

Glad to see I’m not the only one who has stopped using route-deferred in favor of a state machine. And for exactly the reasons mentioned - to show a loader (especially important on mobile) and to consolidate the logic in one place.

i’m kinda going back and forth with UISM trying to not introduce it in simple enough cases — FSMs have a cognitive load per se (or I’ve just shoot my feet too often with redux sagas)

@tony.kay so, it’s fine to transact dr/target-ready in parallel with df/load! inside dr/route-deferred arg fn?

no side-effects, at least

*as opposed to chaining tartget-ready as a post-mutation of load

@fjolne.yngling yeah, that should not hurt anything

cool, thanks!