This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-12-19
Channels
- # adventofcode (18)
- # announcements (1)
- # babashka (153)
- # beginners (73)
- # bristol-clojurians (4)
- # calva (1)
- # cider (6)
- # clj-kondo (38)
- # clojure (154)
- # clojure-dev (12)
- # clojure-europe (7)
- # clojure-finland (11)
- # clojure-nl (70)
- # clojure-spec (13)
- # clojure-uk (101)
- # clojuredesign-podcast (2)
- # clojurescript (15)
- # core-async (30)
- # cryogen (1)
- # cursive (5)
- # devops (1)
- # duct (4)
- # figwheel-main (1)
- # fulcro (19)
- # jobs (12)
- # kaocha (17)
- # luminus (2)
- # malli (8)
- # music (5)
- # nrepl (13)
- # off-topic (20)
- # overtone (3)
- # re-frame (7)
- # reagent (38)
- # shadow-cljs (13)
- # specter (3)
- # tools-deps (6)
- # vim (7)
doing df/load with query params worked out very will with your
query-params-to-env-plugin
@tony.kay so thanks for that one .. was very simple to do query params with that pluginon 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?
@fjolne.yngling yeah, that should not hurt anything