This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-07-01
Channels
- # atom-editor (11)
- # babashka (25)
- # beginners (142)
- # boot (9)
- # calva (3)
- # cider (19)
- # clara (15)
- # clj-kondo (6)
- # cljs-dev (20)
- # clojars (11)
- # clojure (164)
- # clojure-dev (9)
- # clojure-europe (6)
- # clojure-italy (17)
- # clojure-nl (3)
- # clojure-spec (19)
- # clojure-sweden (10)
- # clojure-uk (23)
- # clojurescript (34)
- # code-reviews (31)
- # conjure (20)
- # cursive (14)
- # datomic (54)
- # emacs (1)
- # fulcro (51)
- # graalvm (24)
- # graphql (6)
- # helix (3)
- # jobs (3)
- # kaocha (1)
- # malli (2)
- # meander (15)
- # off-topic (81)
- # pathom (2)
- # re-frame (43)
- # reagent (26)
- # reitit (1)
- # releases (1)
- # sci (12)
- # shadow-cljs (29)
- # sql (22)
- # timbre (3)
- # tools-deps (15)
I'm not sure if this was already discussed in a github issue or in here: is there any interest in adding support for shortcut for divs as in sablono:
[:.ui.container>.message "hi"] vs [:div.ui.container>div.message "hi"]
👋:skin-tone-2: trying to debug this nagging cursor jumping issue when editing the middle of text in an input (cursor jumps to the end after change) I’m able to repro with this component
(defn input [{:keys [value on-change]}]
(React/createElement "input" #js {:value value
:onChange on-change}))
I find in practice there usually isn't a reason to have the value of the text area be controlled. An :on-focus
or :on-blur
typically does what is needed, or a submit button if it's within a form element. You can also do some fancier stuff with a type-3 component
@haywood https://github.com/reagent-project/reagent/blob/master/doc/ControlledInputs.md
🙏:skin-tone-2: can’t believe I didn’t stumble upon that thanks a lot this explains it.
Hi, I have a performance question concerning using React Motion with Reagent. I am wrapping the motion component in this way:
(defn motion
"Creates a motion animation component from React Motion.
The first parameter are animation attributes which a map having two maps stored as keys :style
and :defaultStyle.
- The :defaultStyle map describes the initial animation values when the component is mounted. When
the component is later updated, :defaultStyle is ignored.
- The :style map describes the current values which are targets of the animation.
In both maps, the same keys have to be defined and these keys should be written in camelCase instead
of kebab-case.
- All values in :defaultStyle are numbers (nils not supported).
- All values in :style are either numbers (which skips the animation and goes to the value directly),
or are created by calling spring function defined below.
The second parameter is an arbitrary Reagent component. It accepts a single argument which is the
anim-props map containing the values of the current animation state.
The third parameter is an input to the component which is stored unchanged as :data key into anim-props."
[attr component data]
[:> motion/Motion attr
(fn [props]
(when data
(set! (.-data props) data))
(r/create-element (r/reactify-component component) props))])
And using it like this:
(defn- zoom-buttons
[{:keys [opacity]}]
.......)
[anim/motion
{:defaultStyle {:opacity 0}
:style {:opacity (anim/spring opacity)}}
zoom-buttons]
Since we are animating many components at the same time (for a new graph layout), it would be helpful to make everything little bit faster.
For instance, I don't really need that React props are converted into Clojurescript map, I could just access data using js interop.
Or maybe I could make things faster by using some other tricks, not sure.
you could probably move reactify-component
outside of the render fn passed to the motion component
does destructuring works directly on JS objects?
moving reactify-component outside might help, I will test it out
what would you recommend for profiling?
I would always suggest profiling your app to identify places to optimize. It might end up that this component isn't even the performance problem, but some parent component that's updating too frequently, taking too long, or something
I did a change recently with (set! ) which improved the performance quite a bit, so I think there is some bottleneck
before I was converting twice from JS->CLJS->JS
so there is likely more to be saved, the child component just have some styles updated via react
I will have to spend some more time getting used to the profiller, definitely worth investigating, probably I can save more on improving how links are drawn
this is how I can extract reactify-component out?
(let [react-component (r/reactify-component component)]
(fn [attr _ data]
[:> motion/Motion attr
(fn [props]
(when data
(set! (.-data props) data))
(r/create-element react-component props))]))
at the moment I can't decide whether it makes the code faster, or slower, or doesn't matter much at all (profilling makes it too noisy)