Clojurians Log v2

Hello, any good suggestions on how to authenticate SPA with Azure AD? Thanks.

Hey all! I was trying out the following code. When I try to print the atom value outside the button, it doesn't get logged. But inside the onClick fn in the Button, it gets logged. I'm curious why this is happening. Thanks!

(defn view-review-description
  []
  (let [open? (reagent/atom true)]
    (js/console.log "Outside Button" @open?)
    [:div
     [components/Button
      {:onClick
               (fn []
                 (reset! open? true)
                 (js/console.log "Inside button " @open?))

       :style {:margin "0px 5px"
               :color "#00947E"}} "View"]]))

It gets print out just fine for me, just as it should.

BTW you probably want to use reagent/with-let instead of that let. But it won't affect the printing out in any way.

My bad! It works just fine.

How is reagent/with-let different from let ?

With let, you will never be able to set open? to false because it will be reinitialized with (reagent/atom true) on each re-render. reagent/with-let prevents that from happening.

Is with-let equal to reagent form 2?

I think so, yes. But don't quote me on that. :) I didn't delve that deep into its implementation.

Thanks 😊

It happened again. Time after time I see people trying to reuse subscriptions in event handlers, other subscriptions or even functions. I know it's tempting to reuse the code already written without spending more effort. In case of event handlers I can point them to https://github.com/Day8/re-frame/blob/master/docs/FAQs/UseASubscriptionInAnEventHandler.md. In other cases I try to convince people to factor the common part out as a helper / selector / you-name-it, and to try to remain in PureLand, but it's often tedious. I'm not very used to ask questions, but not this time: How do you cope with desire to reuse subscriptions in places other than view components?

I cope by remembering the other parts of re-frame, which are well thought-out 🙂

I'm still new to re-frame, so this is probably a dumb question. In "The Wrong Way" https://github.com/Day8/re-frame/blob/master/docs/FAQs/UseASubscriptionInAnEventHandler.md linked above, it says don't use subscriptions in event handlers > because that subscribe: > might create a memory leak (the subscription might not be "freed") > makes the event handler impure (it grabs a global value) it seems like these drawbacks would also apply to using subscriptions in view components. what's different about view components that make these drawbacks not apply?

components get unmounted and can declare they no longer are interested in the subscription

random functions that are run have no "finished" lifecycle so they never clean up the subscription

that addresses the memory leak issue. what about the impure/global value issue?

are you asking how that makes it impure or why purity is a goal?

consider:

(rf/reg-event-db
 :impure/handler
 (fn [db [_ v]]
   (let [from-db @(rf/subscribe [:app-db/other-value])]
     (assoc db :new-value (+ v from-db)))))

(rf/dispatch [:impure/handler 8])

i'm asking why it's ok for view components to be impure

Ah, ok, that's different 🙂

A view function is not impure, it's a transformation of some or all of the app-db.

why are subscriptions in events impure, but subscriptions in views considered pure?

I don't understand why the drawbacks of subscriptions apply to events, but not to views

obviously, it seems to work, but since I'm new to re-frame, I don't know what the differences are

It's kind of semantics -- the subscriptions in a view actually are arguments to the view function, but because a subscription also incorporates the mechanics of forcing a re-render whenever the data changes, it's easier to express them as if they were function calls inside a let.

Your question is very interesting though because it does highlight some kind of conceptual mismatch between the desired functionality of the view and the way we express that functionality in Clojure.

couldn't [making subscriptions arguments to the function] also be done for events?

Well, could but shouldn't. Event handlers have a different role.

(plus of course the implementation details like leaking memory).

Are you familiar with CQRS?

somewhat

I don't know about anyone else, but re-frame seems to me to be basically a CQRS for UI stuff

it seems like events and views both have mechanisms for injecting subscriptions. for views, I think you just deref a subscription? for events, the subscriptions are on the "outside" of the function:

(re-frame.core/reg-event-fx         ;; handler must access coeffects, so use -fx
  :event-id 
  (inject-sub  [:query-id :param])  ;; <-- interceptor will inject subscription value into coeffects
  (fn [coeffects event]
    (let [sub-val  (:something coeffects)]  ;; obtain subscription value 
       ....)))

I guess it just comes down to ergonomics?

Yeah, that's the canonical way to do it. Event handlers receive coeffects and events, so if you add an effect handler that injects the value of a subscription, you're keeping it theoretically pure--the effect handler isn't accessing any globals that way, it's just operating on the date it receives in its arguments.

I think some of the things you're questioning though are hints that there may be other ways of approaching the whole conceptual framework of subscriptions and effects and event handlers and views, so it's definitely probing into the matter further. But I think if you find good answers to your questions you'll be designing something that builds on re-frame's example in order to create something new and different.

the “problem” with using subscriptions inside of events or effects is that events and effects by design do not participate in the reactive graph

Subscriptions combine ("complect") the problems of "How do I get efficient access to the parts of app-db that I want to render?" and "How do I make sure I re-render components when their underlying data changes?" Maybe there'd be a different way of solving these problems separately that would reduce or eliminate the "subscriptions inside events" prohibition.

so you can end up with “tearing”, where you dereference a subscription in a view, dispatch an event, that event dereferences the subscription and the value has changed between dispatch and running the event

the contract between subscription and component is that when a subscription changes, a component will be re-rendered accordingly. there’s no contract like that with events or effects, and because they can be fired ad-hoc asynchronously you cannot depend on multiple dereferences being coherent

I should say, multiple dereferences across frames

my side project has been a clj/cljs based graphics and event library (an alternative to the DOM). based on re-frames success in the browser, my goal is to try to use re-frame as the ui state library. hopefully, I can learn enough about re-frame to make it work well. here's the proof of concept so far, https://github.com/phronmophobic/membrane-re-frame-example

so far, re-frame seems like a pretty good fit. I can reuse all the subs, events, and db for the terminal app and for the desktop app. the view code is different for each

they are queued but you can’t control when a user clicks a button

right, but the event handler doesn't run when the user clicks the button. it runs when re-frame decides to dispatch the event

right?

yes

https://github.com/day8/re-frame/blob/master/src/re_frame/router.cljc#L8-L60

right now, I'm having the opposite problem. I would like to call view functions without having to put data into the global app db.

You mean you have data that you want to keep separate from app-db?

I just want to be able to call a view function and pass in the data rather than put some data in the the app db and then call the view function to see what the view function produces

(todo-item {:description "write code" :completed false})

right now, I have to

(dispatch [:add-todo {:description "write code" :completed false}])
;; then
(todo-item)

i'm probably doing something wrong, but I was following https://github.com/day8/re-frame/tree/master/examples/todomvc see: https://github.com/day8/re-frame/blob/master/examples/todomvc/src/todomvc/views.cljs#L27

You can certainly make a view component with arguments that you pass in and render. I commonly do something like that when rendering tables with rows of data: the parent component gets a list of rows and then creates child components by code very much like your todo-item (except I use square brackets not parens). The thing is, if you write a component that works this way, then (a) where are you getting your data from? and (b) how do you control the rendering/re-rendering? In the case of a parent component rendering a list of rows, then it's straightforward: it gets its data from the parent (which gets it from a subscription), and it re-renders whenever the parent component re-renders.

i realize I'm off in the weeds since I'm trying to use re-frame without reagent. I guess the question you're asking is the same question I'm trying to solve. thanks for taking the time and I totally understand if it's not worth going down this rabbit hole since this isn't how re-frame is intended to be used. currently, my proof of concept doesn't support the square bracket syntax used by reagent. see the todo-item call below:

(defn task-list
  []
  (let [visible-todos @(subscribe [:visible-todos])
        all-complete? @(subscribe [:all-complete?])]
    (apply
     vertical-layout
     (interpose
      (ui/spacer 0 10)
      (for [todo visible-todos]
        (todo-item todo))))))

Ah, without reagent, that explains a lot! 😄