Fork me on GitHub
Ben Sless19:10:16

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]
    (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

Ben Sless19:10:58

Thank you, Going back to the HN reader example:

(defn load-kids
  (when kids
      (map deref)
      (map (fn [{:keys [kids] :as kid}]
             (if kids
               (assoc kid :kids (load-kids kids))
     (mapv fetch-id! kids))))

(defeffect ::load-comments [$comments kids]
  (dispatch! :update $comments (fn [_] (load-kids kids))))
looks like I can arbitrarily dispatch effects in futures

Ben Sless19:10:00

which is excellent

Ben Sless19:10:08

the UI will update dynamically


there 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.

Ben Sless10:10:31

I think I'll try with CF so I can register callbacks


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.

Vincent Cantin15:11:49

RichTextView ... rich