fulcro 2023-03-01 | Slack Archive

Studying this, as I think about a plan of attack of writing a Membrane RAD Report. :) https://clojurians.slack.com/archives/C68M60S4F/p1630421757063300?thread_ts=1630419274.061300&channel=C68M60S4F&message_ts=1630421757.063300

🆒 2

👍 1

Eric Dvorsak09:03:56

what is membrane?

Eric Dvorsak09:03:38

nvm i found it https://github.com/phronmophobic/membrane

Rambabu Patina10:03:58

Hi Guys, I am new to use Fulcro. I have a scenario like on button click first I need to send an event to third party api and then secondly close the modal dialog. Here is the code

:onClick #(comp/transact! this [(send-event!) (close-dialog!)] {:optimistic? false})}

The events are sending properly from first call but not reaching the second call (i.e close-dialog!). The send-event defmutation is like

(m/defmutation send-event! [{:keys []}]
  (remote [{:keys [app state]}]
    (let [{:keys [plg-data module]} (comp/shared app) 
        ....

Rambabu Patina10:03:14

Any idea what I am missing?

tony.kay14:03:50

I'm not sure how we're supposed to help with that, and given that you didn't show the implementation of the second method, nor any details of this modal. My guess would be that you have a typo or something in your second mutation and you're not actually modifying the state in a way that will cause your modal to disappear

Rambabu Patina15:03:57

Hi @U0CKQ19AQ, The second mutation code is here

(defn close-dialog [] (remote/emit-event "dialogClosed") (remote/close-dialog)) // which will close the modal popup
(m/defmutation close-dialog! [_] (action [_] (close-dialog)))

Rambabu Patina15:03:16

With out the first method, second method works fine

tony.kay15:03:14

I don't understand why there are events here. You're doing something very non-standard here. I would expect this to be a simple swap on state changing a flag on the modal component. Have you looked at inspect to see if or when your second mutation is running? I guarantee you that transact itself is not broken

Jakub Holý (HolyJak)11:03:07

I’ve just published a new live coding, introducing an UISM https://www.youtube.com/watch?v=YDeiY0cu5kM Though I see I need to get back and redo it with statecharts 😅

🎉 3

Jakub Holý (HolyJak)12:03:43

I was just joking 😅 But maybe, some other day…

😭 1

😉 1

Jakub Holý (HolyJak)20:03:22

Hello! How to handle when a want a mutation that sometimes returns data? Currently I do have

(remote [env]
             (-> env
                 (m/returning DependenciesList)
                 (m/with-target [:ui/show-deps-for])))

but then, when the server-side mutation returns nil (and thus the HTTP response body is {my-mutation nil}`), the client DB ends up with

{... 
 :ui/show-deps-for [:dependency/id nil] 
 :dependency/id {nil {}}}

I do not see any option to tell Fulcro that the mutation may return nothing and thus nothing should be added to the client DB. I could check and fix the state in ok-action but that feels wrong. 🙏

✅ 1

Björn Ebbinghaus21:03:12

I think returning nil here might not be right. Is „nil“ a „DependencyList“ ?

Jakub Holý (HolyJak)21:03:47

Well, it means “Lucky you, we do not have any dependency list for you to handle!

Björn Ebbinghaus21:03:26

So why not [] ? aka "no dependencies" ?

👀 1

Björn Ebbinghaus21:03:25

But I'm not sure what your mutations does. And thus can't really imply semantics. But I guess you have a tree like:

{:dependency/id 42
 :dependency/dependencies [{:dependency/id 1337}, {:dependency/id 31415}]}

Where :dependency/dependencies nil would semantically be "missing / not loaded / don't know" and [] would be definitly no dependencies.

Jakub Holý (HolyJak)21:03:28

Correct. Your suggestion mostly works. The only downside is that I end up with {:ui/show-deps-for [], ...} where I would have preferred :ui/show-deps-for nil but I can work around that. Thank you!

Björn Ebbinghaus21:03:45

I don't know how your query looks like. Or what your mutation does. :ui/show-deps-for [] sounds … wrong, doesn't it? "Show the dependencies of this DependencyList?" Is that right?

Björn Ebbinghaus21:03:54

It feels like it should be something like:

(defsc Dependency [_ _]
  {:query [:dependency/id, {:dependency/dependencies 1}]}) ; limited recursive query

(-> env
    (m/returning Dependency)
    (m/with-target [:ui/show-deps-for]))

aka "Show the dependencies of this Dependency"

Björn Ebbinghaus21:03:16

Or of course if DependencyList is a "complex" list. (maybe something with different orderings / filters). That model should have a own representation for an empty list.

(defsc DependencyList [_ _]
  {:query [:dependency-list/count
           :dependency-list/filter
           {:dependency-list/dependencies (comp/get-query Dependency)}]})

{:dependency/id 42
 :dependency/dependency-list
 {:dependency-list/count 0
  :dependency-list/filter :dependency-list.order/size-above-1MB
  :dependency-list/dependencies []}}

Björn Ebbinghaus21:03:41

I think you get where I'm going. 😄

2023-03-01

Channels