This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-11-10
Channels
- # alda (28)
- # announcements (7)
- # beginners (79)
- # boot (62)
- # cider (11)
- # cljsjs (12)
- # cljsrn (8)
- # clojure (111)
- # clojure-art (2)
- # clojure-austin (5)
- # clojure-conj (3)
- # clojure-dev (54)
- # clojure-japan (12)
- # clojure-russia (30)
- # clojurescript (354)
- # clojurex (5)
- # cursive (9)
- # data-science (58)
- # datomic (19)
- # editors-rus (3)
- # emacs (7)
- # events (2)
- # hoplon (5)
- # ldnclj (6)
- # lein-figwheel (14)
- # luminus (1)
- # off-topic (10)
- # om (191)
- # onyx (59)
- # re-frame (30)
- # reagent (74)
- # robots (1)
- # yada (19)
@mikethompson: A minimal version is a render function doing (mapv (fn [x] [:p x]) (range 10))
@mikethompson: I noticed hiccup's README says >If the body of the element is a seq, its contents will be expanded out into the element body. This makes working with forms like map and for more convenient: ...
@profil you may want to have a component that encloses all of those p tags. In your example, you will get [ [:p 1] ... ]
, but you need something like [:div [:p 1] ...]
@tomc i do something similar in principle and use cursors for each type of grouping
@profil: the other variation of @gadfly361 excellent advice is this one: (into [:div ] (map (fn [x] [:p x])) (range 10)))
@gadfly361's version is often what you want, but you will (correctly) get messages about needing to provide keys. The version I supplied has pros and cons but no keys will be needed.
Oh awesome! I have been using map-indexed and using the index as the key to silence the warnings. Didnt realize into circumvented that, will check it out :)
The underlying reason for this is as follows ...
With @gadfly361's version ... reagent ends up seeing [: div a-list-in-here]
. It will do the right thing BUT it will expect those list elements to have keys.
With my version, reagent will not ever see a list. It sees instead: [:div [:p 1] [:p 2] ... [:p 10]]
Just a word of warning: there is no right or wrong here. Just consequences.
If your list is fairly dynamic, you ABSOLUTELY want to be using @gadfly361's version. And you'll want to add those keys to each item in the list, so you help React be efficient when you, for example, delete the top item in the list (and all the other components have to shuffle up by one).
On the other hand, if your list is fairly static, and adding keys is a pain in the behind, then my version will serve you well.
Just to add a reference to a version that should silence the warnings. However, in my experience, most of the seqs i make are static and dont benefit from react's tracking of keys, so i plan to start using @mikethompson into
for most situations!
It is a thing of beauty when the fit is right
@profil: if you really want to understand what was going wrong with your version read this: https://github.com/Day8/re-frame/wiki/Using-%5B%5D-instead-of-%28%29#appendix-2
(mapv (fn [x] [:p x]) (range 10))
will result in [[:p 0] [:p 1] [:p 2] [:p 3] .... [:p 10]]
and reagent will try to interpret [:p 0]
as a render function (because it is the first element of a vector)
@mike: reagent is UI only.
For flux-like, you might be interested in:
- re-frame
https://github.com/Day8/re-frame
But neither of these address falcor or relay
@mikethompson: thanks! what's the major difference between the two frameworks? (apart from the # of github stars)
@mike zelkova
is faithfully Elm-like (which is a good thing)! re-frame
took inspiration from many places including Flux and Elm. (I'm the author of re-frame so won't get a useful comparison out of me).
BTW, React/Flux is dead. It is sooo early 2015.
Long live Cycle.js
That's the new black .... at least for me
After all, React was created a couple of years ago now. That's the lifetime for a framework, right? Its all over.
I like functional reactive programming, and it seems zelkova, re-frame, hoplon are all slightly different implementation of at least the intended goal of FRP. The creator of Elm, gives a good talk on the taxonomy of FRP that i recommend: https://youtu.be/Agu6jipKfYw
That doesnt answer your question about what's the major difference between zelkova and re-frame, but a cool video to watch nonetheless
I've programmed in virtually every GUI toolkit imaginable, over a long time, going all the way back to hand-crafted C frameworks for Vt100 terminals, to Interviews (C++), Smalltalk/V, MFC, QT, Flex (Flash) ... you name it. (Yes, I'm that old). I have never enjoyed programming GUIs as much as I am now using FRP. Never. It is an absolute pleasure compared to every other framework/paradigm ever. There's no going back for me.
@mikethompson: what specifically? Immutability, first order functions or the dom as a pure function of state or….
(mine would be all three and more :-))
Yes, it tends to be the combination. But I think dom-as-a-pure-function-of-state is central to it all.
thanks Mike. Agreed.
@mikethompson: same here
@mikethompson: by the way, do you have any plans to make anything like re-frame for cycle.js?
There a couple of tweaks coming for re-frame which, I believe, will make it sufficiently flexible that I won't need cycle.js.
I am really looking forward to it. I must say, that re-frame changed how I think about web page. The dom-as-a-pure-function-of-state and messaging about the state is so powerfull. I am more often than not surprised how easily things could be implemented
Interesting side-project for someone though. Putting hiccup on top of cycle.js, etc.
I've been looking at Hoplon, and I like the simplicity of the ideas very much. @mikethompson did you ever try Hoplon out?
I loved the thinking. I don't think it has got nearly enough praise.
I was put off a bit by the tooling issues too
i had an issue having to learn boot, plus, boot felt so slow recompiling hoplon everytime I made a change.
I did a performance test of rendering a table with 10K cells showing a string and then changed 1000 strings in random cells (which was representative of my use-case). Hoplon was great but reagent was far quicker to render.
not making any sweeping statements, only that there is a significant rendering performance difference in some situations
I keep meaning to combine the cell
logic with react…
@roberto: performance will be much better in the upcoming Boot release + keep in mind that hoplon v6 is currently alpha and might not be very well optimized. FWIW you can write slow compiling CLJS code with any compiler-tool
I think it was the rendering, not the cells which was slow
it is definitely “one to watch” though
When I say I was put off by the tooling issues, this was back pre-boot
boot looks a fine bit of work, and I'm looking forward to eventually using it
Thanks @gadfly361 - good to know at least one other person is doing that
Does anyone know how to suppress this message in the Chrome console?
Warning: Returning `false` from an event handler is deprecated and will be ignored in a future release. Instead, manually call e.stopPropagation() or e.preventDefault(), as appropriate.
zs-content.js:18127 Warning: Returning `false` from an event handler is deprecated and will be ignored in a future release. Instead, manually call e.stopPropagation() or e.preventDefault(), as appropriate.
I assume I could just return true
at the end of my event handlers, but was wondering if there’s a better way.(I know this is a React message, but I’m using Reagent)
your handler takes an argument that is the dom event, call preventDefault
on it. That is how I solve that. Don’t know if there is a “more idiomatic” way.
roberto: right, but do I have to do that in every single Reagent event handler? I don’t even particularly want to prevent default in all cases…
I just want to suppress this warning
Looks like mikethompson has already documented a way of dealing with this: https://github.com/reagent-project/reagent/wiki/Beware-Event-Handlers-Returning-False (Though it seems like there ought to be a way to just disable the warning and not have to wrap my event handlers.)
@erik_price: React is deprecating a feature (returning false was a feature), hence the warnings.