This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-02-13
Channels
- # announcements (12)
- # babashka (88)
- # beginners (60)
- # biff (10)
- # calva (56)
- # clerk (9)
- # clj-kondo (5)
- # clojure (70)
- # clojure-austin (3)
- # clojure-conj (2)
- # clojure-dev (69)
- # clojure-europe (53)
- # clojure-nl (1)
- # clojure-norway (28)
- # clojure-uk (1)
- # clojurescript (27)
- # copenhagen-clojurians (3)
- # cursive (10)
- # datascript (1)
- # datomic (10)
- # fulcro (3)
- # funcool (1)
- # garden (7)
- # helix (5)
- # holy-lambda (5)
- # hyperfiddle (39)
- # introduce-yourself (6)
- # jobs-discuss (15)
- # lsp (3)
- # malli (5)
- # membrane (19)
- # missionary (1)
- # nrepl (6)
- # off-topic (44)
- # pathom (17)
- # pomegranate (3)
- # react (7)
- # releases (1)
- # shadow-cljs (39)
- # tools-deps (16)
- # xtdb (28)
HI all, can I ask for a quick sanity check as we’re dealing with a bug in our code that manifests during tests but not in the browser; is it valid to call com.fulcrologic.rad.routing/route-to! within a deferred route?
We have a deferred route that issues a load, if the server indicates that the entity is inaccessible we change the route before and without calling route-ready!. This works in the browser but fails in our test suite. We upgraded Fulcro from 3.5.24 -> 3.6.0 which didn’t exhibit the bug but upgrading RAD 1.1.0-RC4 -> 1.4.5 (and in fact a few versions we tested beyond 1.1.0-RC4 also surfaced the bug)
Routing is done through transactions, which are async, and may not test well. Route deferral is really meant for I/O and not decision-making. I would recommend writing your own decision logic outside of routing, and put your I/O there if you have decision logic. Don’t use routing as a general-purpose logic tool.