This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-06-25
Channels
- # announcements (2)
- # asami (16)
- # babashka (55)
- # beginners (27)
- # calva (14)
- # cider (5)
- # clj-kondo (16)
- # cljs-dev (22)
- # clojure (72)
- # clojure-europe (89)
- # clojure-nl (10)
- # clojure-uk (7)
- # clojured (1)
- # clojurescript (14)
- # community-development (4)
- # core-async (15)
- # emacs (10)
- # events (2)
- # fulcro (3)
- # graalvm (1)
- # graalvm-mobile (71)
- # helix (7)
- # honeysql (2)
- # introduce-yourself (1)
- # jobs-discuss (17)
- # juxt (3)
- # lsp (62)
- # malli (13)
- # meander (7)
- # off-topic (14)
- # pathom (54)
- # polylith (6)
- # re-frame (11)
- # releases (1)
- # sci (22)
- # sql (9)
- # tools-deps (84)
- # vim (37)
- # xtdb (18)
Anyone has tried splitting view defns into pure and impure parts? (systematically, at scale)
For example in https://github.com/jacekschae/conduit/blob/732d56d5bd981bd47fab3cdd1b2d96ea27b1e7ff/src/conduit/views.cljs#L209-L216 , the @(subscribe
part makes the defn impure, which might preclude some techniques.
I figured the splitting could make sense: it would be akin to the controller<->view separation in MVC frameworks. The "C" part would handle state and the "V" part would be a pure fn of app-data -> hiccup
signature
It's a balance. Having impure components does indeed preclude some techniques. But having all components consist of a pure fn + an impure one will make it harder to write and support. So if you need some of those techniques for all or for the majority of the views - sure, it makes sense. But if you need them only for some - I would split only those few view functions.
Basically I'm interested in whether it would work at all (beyond a basic example), perhaps some experience report Supporting it might be less painful than it sounds - if one settles in using a MVC-like project structure, then splitting concerns would come quite naturally and mechanically i.e. many devs appreciate a proliferation of defns, files etc even when they know they could inline everything over one defn
To be clear - it has only one layer, the pure functions. It doesn't depend on re-frame at all - that part is up to the user.
There’s also this small library I wrote that provides another flexible way of creating form-1 components: https://github.com/sansarip/peanuts you can play around with it in the https://sansarip.github.io/peanuts/#!/peanuts.cards.main.
That looks neat. It's useful that you point out performance - I suspected there was that possible drawback.
Btw have you tried an API in this style? (defn vanilla-defn)
+ (defc my-component vanilla-defn)
So one sticks to vanilla clojure.core defns, increasing the confidence in whether magic is in fact reduced. Also would mean automatic support for :pre/:post and the other things you point out
If I understand you correctly, that’s actually supported 🙂 That was the original implementation. If you look at an https://github.com/sansarip/peanuts/tree/5499859a2a00d37454256312b1d784c80ddb6587, you’ll see info on defc
and fnc
.
Unfortunately due to how the macro works, you’d need to inline your vanilla defn
e.g.
(defc my-component (fn []))
This is because defc
actually will dissect your vanilla-fn
to get at the parameters it accepts and injects a bit of code into it.
defc
and fc
are still around in the latest version, alongside the newer defnc
and fnc
macros