Fork me on GitHub
#re-frame
<
2016-09-09
>
michael.heuberger00:09:26

sorry guys, never mind. my question yesterday is a false alarm. all good now.

mikethompson05:09:30

@nilrecurring animations is an area for which I wish we (using Reagent) had better declarative solutions. You can go a long way with CSS animations - but they sometimes require real CSS, rather than inline styles. But the harder ones are entry and exit animations. Exit is the hardest. React has some solutions: https://facebook.github.io/react/docs/animation.html

mikethompson05:09:37

In case, anyone has time on their hands, my dream solution for entry and exit would be something like this:

[:div  {:width  "200px"  
        :background "red"
        :exit  {:opacity "0'" :height 0}}    ;;  when being removed morph to these attributes from the existing ones  
        :entry {:background "white"}         ;;  when being added morph from these attributes to the standard ones 
    "hello"]   

mikethompson05:09:58

declaratively state what should happen when this element is added and removed from the DOM

superstructor06:09:43

I’ve found the 3rd sugar form of reg-sub can be somewhat confusing @mikethompson i.e.

(reg-sub :b
  :<- [:a]
  (fn [a _]
    ;; a is not a vector so not e.g. [[a] _]
  ))
;; vs
(reg-sub :c
  :<- [:a]
  :<- [:b]
  (fn [[a b] _]
   ;; is a vector, so destructure with e.g. [[a b] _] 
  ))

superstructor06:09:48

Also, suggest that ordering of args means nothing, so possibly a better data structure would be a map keyed by subscription name like:

(reg-sub :c
  :<- [:a]
  :<- [:b]
  (fn [{:keys [b]} _]
    ;; destructured b based on the sub-name, not on ordering
  ))
@mikethompson ?

nilrecurring06:09:12

That would be a great declarative syntax. My issue at the moment is polluting the place with all the animation-related stuff, that should ideally be abstracted away

mikethompson06:09:53

@superstructor I'm not sure what you mean by 3rd sugar form. The sugar forms mirror what is possible via providing a signals fn

mikethompson06:09:29

(reg-sub :b
  (fn [_ _]    (subscribe [:a]))
  (fn [a _]
    ;; a is not a vector so not e.g. [[a] _]
  ))

mikethompson06:09:10

(reg-sub :c
 (fn [_ _]   
    [   (subscribe [:a])
        (subscribe [:b])
    ])                        ;; on a separate line for dramatic effect
  (fn [[a b] _]
   ;; is a vector, so destructure with e.g. [[a b] _] 
  ))

mikethompson06:09:51

Not mentioned by you, but added here for completeness ... this is also possible in a signal function (no equivalent available via sugar)

(reg-sub :c
 (fn [_ _]   
     {:a  (subscribe [:a])
      :b  (subscribe [:b])})     ;; returning a map !!!
  (fn [{:keys [a b]} _]
       ;; 1st param is now a map, so destructure with :keys 
  ))

mikethompson06:09:05

So signal functions can return: 1. A single reactive value 2. A vector of reactive values 3. A map where the values are reactive values But, via sugar, only 1 and 2 are available

superstructor08:09:24

@mikethompson sure sorry for the confusion by “3rd sugar form” I mean the 3rd variation of reg-sub which is specifically the sugar form. I mean that with :<- it would be nice if the default was a map instead of a vector ?

mikethompson08:09:13

@superstructor I'm afraid that ship might have sailed now that v0.8.0 is released.

superstructor08:09:50

@mikethompson yep fair enough. I thought that would be likely as its a breaking change. So my backup plan is to provide my own reg-subm to adapt reg-sub sugar to use map by default. Do you think something like that or alternative sugar syntax could be supported in re-frame itself ?

mikethompson08:09:37

I probably don't see enough difference between:

(fn [{:keys [a b]} _]
and
(fn [[a b] _]

mikethompson08:09:01

to warrant extra sugar. In fact, I kinda like the terseness of the later (which is perhaps why I did it that way 🙂 )

mikethompson08:09:31

So it will be hard to convince me that we need more sugar around maps.

manishkumarmdb09:09:14

how to call cljs-ajax at hiccup style :href link in re-frame

m9dfukc10:09:33

Hi, what’s the appropriate way to debounce a dispatch in re-frame? … just for the record, I’m coming from here https://github.com/Day8/re-frame/issues/233

manishkumarmdb11:09:28

@pesterhazy but i want to use :href link

pesterhazy12:09:35

then add a cljs fn, mark it as :export and refer to its mangled name: "manish.kumarm.db()"

pesterhazy12:09:00

in the href attr

martinklepsch12:09:44

@manishkumarmdb why do you want to use an a tag and href for javascript functionality?

manishkumarmdb12:09:06

@martinklepsch i don't want to use input type, just for practice

martinklepsch12:09:13

[input {:type "button"} ...] you mean?

manishkumarmdb12:09:59

@martinklepsch have you any idea about this way to implement

rorydouglas13:09:25

this is a re-com question because there’s no specific re-com channel: single-dropdown requires the choices vector to be a vector of maps (validate fn is vector-of-maps?). For very simple use cases it would be useful for it to just accept a vector of Strings & set id-fn and label-fn to identity - is there a specific reason this was not allowed? @mikethompson

lwhorton13:09:58

@m9dfukc i’ve had good luck simply storing a local atom as a debounced setTimeout, as you would do in javascript, that times out to a dispatch

lwhorton13:09:29

just be sure to clearTimeout on unmount or other such situations

lwhorton13:09:36

(otherwise debouncing on the other end - in the handler, or as an fx, floods the system with unnecessary messages, particularly on input fields)

martinklepsch14:09:36

@manishkumarmdb: I'd just advise to use buttons :D

manishkumarmdb14:09:04

@martinklepsch thanks, i know using input type, but i want just knowing about that way, because some time no need to use input type