Fork me on GitHub
#reagent
<
2015-11-10
>
profil01:11:25

@mikethompson: A minimal version is a render function doing (mapv (fn [x] [:p x]) (range 10))

profil01:11:47

@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: ...

profil01:11:35

Is that something that reagent does?

gadfly36101:11:05

@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] ...]

gadfly36101:11:55

Try [:div (map (fn [x] [:p x]) (range 10))].

gadfly36101:11:22

@tomc i do something similar in principle and use cursors for each type of grouping

mikethompson01:11:43

@profil: the other variation of @gadfly361 excellent advice is this one: (into [:div ] (map (fn [x] [:p x])) (range 10)))

mikethompson01:11:06

@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.

gadfly36101:11:40

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 :)

mikethompson01:11:43

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]]

mikethompson01:11:41

Just a word of warning: there is no right or wrong here. Just consequences.

mikethompson02:11:45

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).

mikethompson02:11:16

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.

gadfly36102:11:18

[:div (map-indexed (fn [i x] ^{:key i} [:p x]) (range 10))]

gadfly36102:11:45

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!

mikethompson02:11:56

It is a thing of beauty when the fit is right simple_smile

mikethompson02:11:01

@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

mikethompson02:11:48

(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)

mike06:11:27

is reagent only the ui?

mike06:11:28

does it support flux/relay/falcor like architecture?

mikethompson06:11:39

@mike: reagent is UI only. For flux-like, you might be interested in: - re-frame https://github.com/Day8/re-frame

mikethompson06:11:35

But neither of these address falcor or relay

mike06:11:11

@mikethompson: thanks! what's the major difference between the two frameworks? (apart from the # of github stars)

mikethompson08:11:52

@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).

mikethompson08:11:16

BTW, React/Flux is dead. It is sooo early 2015.

mikethompson08:11:25

Long live Cycle.js

mikethompson08:11:34

That's the new black .... at least for me simple_smile

mikethompson08:11:32

After all, React was created a couple of years ago now. That's the lifetime for a framework, right? Its all over.

gadfly36108:11:24

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

gadfly36108:11:50

That doesnt answer your question about what's the major difference between zelkova and re-frame, but a cool video to watch nonetheless

mikethompson08:11:01

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.

colin.yates13:11:06

@mikethompson: what specifically? Immutability, first order functions or the dom as a pure function of state or….

colin.yates13:11:22

(mine would be all three and more :-))

mikethompson13:11:21

Yes, it tends to be the combination. But I think dom-as-a-pure-function-of-state is central to it all.

colin.yates13:11:26

thanks Mike. Agreed.

pepe13:11:07

@mikethompson: by the way, do you have any plans to make anything like re-frame for cycle.js?

mikethompson13:11:26

There a couple of tweaks coming for re-frame which, I believe, will make it sufficiently flexible that I won't need cycle.js.

pepe13:11:04

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

mikethompson13:11:07

Interesting side-project for someone though. Putting hiccup on top of cycle.js, etc.

pepe13:11:10

I wish, I am better in clojurescript, so I can help. But green as grass I am 🐤

dm313:11:32

all so true

dm313:11:30

I've been looking at Hoplon, and I like the simplicity of the ideas very much. @mikethompson did you ever try Hoplon out?

roberto13:11:50

I tried Hoplon, I didn’t like the tooling.

mikethompson13:11:29

I loved the thinking. I don't think it has got nearly enough praise.

roberto13:11:31

but Hoplon is nice, I enjoyed it

mikethompson13:11:48

I was put off a bit by the tooling issues too

roberto14:11:01

i had an issue having to learn boot, plus, boot felt so slow recompiling hoplon everytime I made a change.

roberto14:11:32

I would try it again if I didn’t have to use boot instead of just lein with figwheel

dm314:11:35

they're working hard at #C053K90BR simple_smile

colin.yates14:11:36

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.

colin.yates14:11:58

not making any sweeping statements, only that there is a significant rendering performance difference in some situations

colin.yates14:11:25

I keep meaning to combine the cell logic with react…

dm314:11:46

think better avenue is making cells fast without react

dm314:11:59

(or whatever is causing performance issues)

dm314:11:11

as absence of react is one of the bigger advantages of Hoplon

martinklepsch14:11:24

@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 simple_smile

colin.yates14:11:26

I think it was the rendering, not the cells which was slow

colin.yates14:11:59

it is definitely “one to watch” though

dm314:11:14

nice to hear more opinions simple_smile

mikethompson14:11:39

When I say I was put off by the tooling issues, this was back pre-boot

mikethompson14:11:06

boot looks a fine bit of work, and I'm looking forward to eventually using it

tomc14:11:11

Thanks @gadfly361 - good to know at least one other person is doing that simple_smile

erik_price19:11:24

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.

erik_price19:11:44

(I know this is a React message, but I’m using Reagent)

roberto19:11:06

dom-event.preventDefault()

roberto19:11:56

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.

erik_price19:11:04

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…

roberto19:11:05

But it is also a common thing to do in JS

erik_price19:11:16

I just want to suppress this warning

roberto19:11:10

hmm, not sure, I’ve never had the use case where I needed to propagate the event.

erik_price19:11:13

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.)

mikethompson23:11:56

@erik_price: React is deprecating a feature (returning false was a feature), hence the warnings.