This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-09-24
Channels
- # announcements (6)
- # architecture (9)
- # aws (2)
- # babashka (49)
- # beginners (160)
- # boot (19)
- # calva (9)
- # cider (16)
- # clj-kondo (17)
- # cljfx (9)
- # clojure (143)
- # clojure-australia (5)
- # clojure-berlin (1)
- # clojure-czech (3)
- # clojure-europe (64)
- # clojure-france (1)
- # clojure-italy (12)
- # clojure-nl (4)
- # clojure-spec (6)
- # clojure-uk (47)
- # clojurescript (27)
- # code-reviews (5)
- # conjure (45)
- # cursive (47)
- # datascript (2)
- # datomic (21)
- # events (1)
- # fulcro (9)
- # graalvm (4)
- # graphql (2)
- # jackdaw (22)
- # jobs (3)
- # kaocha (6)
- # london-clojurians (1)
- # luminus (4)
- # malli (19)
- # meander (136)
- # pathom (4)
- # pedestal (2)
- # re-frame (15)
- # reitit (2)
- # remote-jobs (2)
- # rum (12)
- # sci (1)
- # shadow-cljs (100)
- # spacemacs (10)
- # sql (1)
- # tools-deps (30)
- # vrac (1)
- # xtdb (30)
Can I just nest dynamic-routers (`com.fulcrologic.fulcro.routing.dynamic-routing/defrouter`) with RAD forms like one can compose legacy-routers as described here? http://book.fulcrologic.com/#_composing_routers Couldn't figure it out by myself yet. I basically wan't some forms to be accessible as dedicated page like in the RAD example, but also as a pop-over/modal on another page
A form/report is just a component; however, if it isn’t used as a route target then you will need to call the form/report startup stuff that is in the will-enter of either (see source of macros)
Ah yes the form/create!
calls, I've seen them. Yeah that should work.
I was trying to make the same form a router-target in the top-level and the nested router, assuming the nested router could add a prefix somehow.
so e.g. /element/edit/xxxx
and in the nested router: /nested/element/edit/xxxx
I’m happy to announce a better extensible type system for Fulcro’s on-the-wire protocol. Fulcro uses transit, but because so many functions have to create readers/writers it can be really hard to make sure all parts of the stack get extended properly when you want to add custom readers/writers for transit. Fulcro 3.3.6 now includes a custom type registry where you can specify how to encode/decode things (using a unified API) for CLJC. Fulcro Websockets was also updated (version 3.2.0) to support the type registry All other libraries use facilities that were already baked into these two libraries, so the entire Fulcro ecosystem should “just work” with extended data types on the wire now (handle-api-request for server middleware, http remote, transit-clj->str, transit-str->clj, etc). The book (and websockets README) have been updated to reflect the new usage. http://book.fulcrologic.com/#_custom_type_support This is a NON-breaking change (though 3.2.0 of websockets requires 3.3.6+ of Fulcro, of course). Anything you’re currently doing to add transit stuff to Fulcro is still there, just no longer necessary. I plan on also adding some cool extended support in the next big release of Inspect: Inspect runs in a different VM, so I can’t see your custom type handlers, BUT I can see your custom tag names and the “ground data” that is used to build up a given type. Thus, I should be able to install cljs readers that will allow you to use your custom types in the “Query” tab. For example:
(deftype Point [x y])
(transit/install-type-handler!
(transit/type-handler Point "geo/point"
(fn [^Point p] [(.-x p) (.-y p)])
(fn [[x y]] (Point. x y))))
is what you’d use (in CLJC) to install support for a Point. Inspect query should then let you do this:
#geo/point [22 44]
to input a Point