This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-09
Channels
- # admin-announcements (1)
- # beginners (78)
- # boot (36)
- # cider (13)
- # cljs-dev (15)
- # cljsjs (3)
- # cljsrn (10)
- # clojure (99)
- # clojure-austin (1)
- # clojure-australia (1)
- # clojure-italy (14)
- # clojure-korea (17)
- # clojure-norway (1)
- # clojure-russia (42)
- # clojure-sg (1)
- # clojure-spec (50)
- # clojure-uk (80)
- # clojurebridge (24)
- # clojurescript (83)
- # community-development (10)
- # conf-proposals (36)
- # core-async (12)
- # cursive (20)
- # datomic (38)
- # hoplon (63)
- # lambdaisland (2)
- # leiningen (6)
- # nyc (2)
- # om (54)
- # om-next (52)
- # onyx (129)
- # planck (15)
- # re-frame (38)
- # reagent (2)
- # rethinkdb (8)
- # specter (1)
- # untangled (2)
sorry guys, never mind. my question yesterday is a false alarm. all good now.
@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
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"]
declaratively state what should happen when this element is added and removed from the DOM
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] _]
))
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 ?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
@superstructor I'm not sure what you mean by 3rd sugar form. The sugar forms mirror what is possible via providing a signals fn
(reg-sub :b
(fn [_ _] (subscribe [:a]))
(fn [a _]
;; a is not a vector so not e.g. [[a] _]
))
(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] _]
))
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
))
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
@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 ?
@superstructor I'm afraid that ship might have sailed now that v0.8.0 is released.
@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 ?
I probably don't see enough difference between:
(fn [{:keys [a b]} _]
and
(fn [[a b] _]
to warrant extra sugar. In fact, I kinda like the terseness of the later (which is perhaps why I did it that way 🙂 )
So it will be hard to convince me that we need more sugar around maps.
In https://github.com/Day8/re-frame/blob/v0.7.0/src/re_frame/subs.cljs#L46 wouldn't @sub
suffice instead of (reaction @@sub)
?
how to call cljs-ajax at hiccup style :href link in re-frame
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
@manishkumarmdb use on-click
instead
@pesterhazy but i want to use :href link
then add a cljs fn, mark it as :export
and refer to its mangled name: "manish.kumarm.db()"
in the href
attr
@manishkumarmdb why do you want to use an a
tag and href
for javascript functionality?
@martinklepsch i don't want to use input type, just for practice
[input {:type "button"} ...]
you mean?
@martinklepsch have you any idea about this way to implement
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
@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
(otherwise debouncing on the other end - in the handler, or as an fx, floods the system with unnecessary messages, particularly on input fields)
@manishkumarmdb: I'd just advise to use buttons :D
@martinklepsch thanks, i know using input type, but i want just knowing about that way, because some time no need to use input type