Fork me on GitHub

@qqq yeah, it is quite amazing how straight forward widgets can be to create these days. I'm an older programmer and I can remember when a tree widget (non HTML) could only be written by a select few. They were normally provided via BIG companies via "toolkits" like QT or MFC.


@mikethompson: what's even crazier is how short (and I'm sure it can be made shorter) an impl is:

(gm/c-defn make-elem-vlist [s-atm ind path lst]
  (pprint {:ind ind :path path :lst lst})
   :children (into []
                   (for [item lst]
                     [make-elem s-atm ind path item]))])

(gm/c-defn make-elem [s-atm ind path [item lst]]
  (pprint {:ind ind :path path :item item :lst lst})
  (let [nm (:name item)
        k (:key item)
        pad (apply str (repeat ind " "))]
    (if (empty? lst)
       :class "mainSidebarItem"
       :label (str pad "* " nm)
       :style {:font-family "Monospace"
               :white-space "pre"}
       :on-click (fn [& rst] (reset! s-atm (conj path k)))]
      (let [expanded? (reagent.core/atom false)]
        (fn []
          (let [header [re-com.core/label
                        :label (if @expanded?
                                 (str pad "- " nm)
                                 (str pad "+ " nm))
                        :style {:font-family "Monospace"
                                :white-space "pre"}
                        :class "mainSidebarItem"
                        :on-click (fn [& rst] (swap! expanded? not))]]
            (if-not @expanded?
               :children [header
                          [make-elem-vlist s-atm (+ ind 1) (conj path k) lst]]])))))))


that's literally my entire tree widget


having just successfully done my first basic re-frame demo, I'm curious as to a business need we have -- drag and drop. Is it possible? If so, any proofs of concept out there?


@joshjones: when you figure this out, can you DM me the solution too?


drag and drop within the dom, or for dropping files into the browser?


Ah.. I’ve tried to roll my own a number of times but not been satisfied with what I ended up with… getting drag and drop working across browsers is a pain point for sure.


@qqq: To answer your re-com question above re centering multiple components around a horizontal line (, refer to the following code:


 :gap      "20px"
 ;; :align    :center
 :children [[box
             :width  "100px"
             :height "60px"
             :style  {:background-color "yellow"}
             :child  ""]
             :md-icon-name "zmdi-star"
             :on-click     #()]
             :label     "THREE"
             :model     true
             :on-change #()]]]


Rendering the code above will align the components at the top of the h-box. Now, uncomment the :align :center line and you'll see what you were after.


You can also align them to the bottom of the h-box with :end. :start is the default.


Note: This is also available for the v-box and does the same thing, but vertically.


@mikethompson re-frame-storage working fine so far :thumbsup:


@sandbags I am working on a buddy-authenticated re-frame SPA, too. Not using JWT, just plain old session cookie. Unfortunately not open source. I could share some mechanics privately, though.


@ska you may want a more generic :location effect


@danielcompton So you suggest returning {::location "/logout"}} instead of {{::logout-fx true}}?


And while I am at it, is this the supposed way of doing AJAX calls? I've been hand-rolling my own but would replace them with this library if that is more idiomatic.


It's just one way you can do it, not canonical


@ska thanks, it would be interesting to hear a little more about the flow of your app thanks


In the context of using boot, as well as adzerk/boot-reload, how should re-frame 0.9's new function clear-subscription-cache! be used please?


@limist I don’t think you’d call it during reloads or similar if that’s what you’re asking


@martinklepsch Ah, that's what/how I thought it would be used; so is it simply not needed w/ boot, or...?


@limist I think I might be wrong. You should call them in reloads. Consult the boot-reload docs for how to do that


In the re-frame simple example line 67 (, this code is given:

(defn color-input
   "Time color: "
   [:input {:type "text"
            :value @(rf/subscribe [:time-color])
            :on-change #(rf/dispatch [:time-color-change (-> % .-target .-value)])}]])
This component returns basic hiccup and not a rendering function, thus, it will be called many times during its life cycle. Doesn’t this mean that (rf/subscribe …) will be called many times also? And if so, isn’t this problematic?


@joshjones subscriptions are cached. The subscribe call this time will just pick up the subscription created last time.


great, good to know @mikethompson — pardon my newbish question, but then is the primary benefit of form 2 over form 1 that setup code which is unnecessary to run each time, is only run once in form 2, prior to returning the renderer?


Yes, that's right. Also Form-2 alloews the renderer to close over local state


typically stored in a ratom


excellent, thanks for being available to answer that mike


"A sanity hint for incoming uncaught error: return (target_fn.cljs$core$IFn$invoke$arity$1 ? targetfn.cljs$core$IFn$invoke$arity$1(a) : targetfn. <<< :radioactive_sign: NULL :radioactive_sign: <<< call(null,a));" gosh, where would I be without that hint....