This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-10-25
Channels
- # announcements (22)
- # babashka (9)
- # beginners (33)
- # biff (12)
- # calva (17)
- # cider (64)
- # cljdoc (3)
- # cljfx (16)
- # clojure (125)
- # clojure-bay-area (14)
- # clojure-europe (15)
- # clojure-norway (64)
- # clojure-uk (2)
- # clojurescript (7)
- # conjure (1)
- # core-async (4)
- # cursive (6)
- # data-science (14)
- # datahike (8)
- # datomic (6)
- # defnpodcast (4)
- # emacs (5)
- # events (1)
- # hyperfiddle (15)
- # leiningen (17)
- # lsp (8)
- # membrane (27)
- # off-topic (25)
- # podcasts-discuss (4)
- # polylith (6)
- # portal (21)
- # reagent (11)
- # releases (1)
- # shadow-cljs (36)
- # slack-help (2)
- # sql (1)
- # squint (131)
- # testing (12)
- # xtdb (7)
Is there a way to specify lifecycle opts when using create-app or is the expected workflow to just create the render manually at that point?
create-app is basically an example of how you compose different pieces of cljfx together, not THE way to do apps
I never use it, and after using cljfx for a long time I now also don't use context, effects and co-effects
That makes sense. What sort of effect model do you use now? Just bind event handlers directly to the events and explicitly pass state down the tree?
I use event maps with handler functions in them:
{:fn my-handler}
The opt map event handler is usually something like #((:fn %) %)
there is usually a state though, and usually the handler updates the state. If all handlers are safe to retry, the map event handler function looks like this: #(swap! the-state (:fn %) %)
, and actual handlers used in descs receive two args — state and event object, and return new state, which is semantically very nice
There might be situations though where it’s not safe to retry event handlers. In this case, I use a slightly different approach: the map event handler is #(swap! the-state ((:fn %) %))
— the handler is invoked only once, and it has to return a function that will then be used to change the app state, and that returned function is retryable
so doing side effects without any changes to the app state is done by performing the side effect in the handler, and returning identity
Instead of {:fn my-handler}
, I use {:type ::my-kw}
with multi-method dispatching on :type
but it’s basically the same with extra layer of indirection via keyword+multimethod. If I was making reveal from scratch again, I’d use :fn
approach
Thanks! And thanks for the library. It’s been very nice to use once it clicked. And what do you use instead of context? Just explicitly pass state between components?