This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-27
Channels
- # announcements (13)
- # asami (12)
- # babashka (65)
- # beginners (62)
- # calva (14)
- # cider (8)
- # clara (11)
- # clj-kondo (16)
- # clojure (86)
- # clojure-europe (12)
- # clojure-gamedev (4)
- # clojure-nl (2)
- # clojure-sg (4)
- # clojure-uk (5)
- # clojurescript (206)
- # clojureverse-ops (11)
- # community-development (7)
- # conjure (12)
- # core-async (2)
- # core-logic (13)
- # cursive (49)
- # datalevin (1)
- # datomic (30)
- # deps-new (3)
- # duct (8)
- # events (5)
- # fulcro (10)
- # helix (5)
- # jobs (1)
- # klipse (5)
- # lsp (178)
- # luminus (1)
- # malli (8)
- # meander (3)
- # membrane (13)
- # missionary (1)
- # nrepl (5)
- # other-languages (4)
- # pedestal (4)
- # reitit (3)
- # releases (1)
- # reveal (27)
- # shadow-cljs (89)
- # tools-build (6)
- # tools-deps (11)
- # vim (2)
- # xtdb (64)
How should asynchrony be handled in membrane? can I emit effects asynchronously? If things run in futures, how do I get the data back? another effect? maybe completable future and emit the effect on complete?
Membrane purposefully doesn't include much for effects since how effects should be handled should be use-case driven. Membrane is meant to work with whatever effects system makes sense for your use case.
For any event handler, it only makes sense to return intents synchronously, but they can be handled synchronously or asynchronously as needed.
Within a defeffect
, you can use futures along with dispatch!
.
(defeffect ::increment-number [$num]
(future
(dispatch! :update $num inc)
(prn (dispatch! :get $num))))
If you're using the builtin membrane.component
stuff, then the :update
and :set
effects will update app state
When you create your view-fn with membrane.component/make-app
, you can pass in the atom to use for the app state. So another option is just to use an add-watch
on the atom.
The docs could be improved on this topic, but it was a design goal that membrane doesn't dictate these sorts of decisions like how asynchrony should work. If you have a few more details about your use case, I can provide a more helpful response for what that might look like with membrane.
I think it's an anti pattern when you have React db, and a React debugger, and a React effects system. All this stuff should be composable
Thank you, Going back to the HN reader example:
(defn load-kids
[kids]
(when kids
(into
[]
(comp
(map deref)
(map (fn [{:keys [kids] :as kid}]
(if kids
(assoc kid :kids (load-kids kids))
kid))))
(mapv fetch-id! kids))))
(defeffect ::load-comments [$comments kids]
(dispatch! :update $comments (fn [_] (load-kids kids))))
looks like I can arbitrarily dispatch effects in futuresthere are 2 caveats:
• if you don't use a futures, you can still tie up the main thread
• if you do use futures, you may need to call repaint. I've been meaning to add a builtin :repaint
effect, but haven't gotten around to it yet.
I still haven't forgotten about the RichTextView. I made some improvements to how fonts are looked up and loaded that were required, but still need to package that into something that makes it easy to use.