@samuel.wagen I am using Draft.js with reagent. here's a gist https://gist.github.com/nrfm/0c33d297e8ae5cf36c98ef640003a118

@fj.abanses - thanks, I'll take a look

👍

I'm trying to understand how reagent actually works. Why do the binding of this, and then rebinding it both to the js this value ant the first argument via .cal at https://github.com/reagent-project/reagent/blob/master/src/reagent/impl/component.cljs#L179? Wouldn't it be simpler to just do (f c)

@tomi.hukkalainen_slac there are many mysteries I don’t understand about reagent, but I think what this code does is insert this as the first argument when calling the lifecycle methods. so when you build a form-3 component, the componentWillUpdate method will take this as the first argument so that you have access to the underlying react object

Yes, but I was thinking that you could also do that with a simple call of (f c rest). Now it seems like it wants to call a javascript function, and make sure that the this is the first parameter but also the javascript this (however you call it), but that's weird. Why would reagent components have javascript lifecycle methods?

They cannot be usual react lifecycle methods exactly because the first parameter has been added, so then you'd call it like (.call f c rest), without doubling the c

that’s true. it is probably redundant to bind the interior function and pass it. i’m trying to think if there are compatibility reasons why it would be surprising if the interior lifecycle function’s this was bound to a different object (i.e. if you call helper functions or something).

ah. here’s why

Call component functions with this set to current component

This makes us more consistent with React classes, and gives more
informative stack traces sometimes.

Also stop wrapping unknown methods - let React deal with them directly.

https://github.com/reagent-project/reagent/commit/253cb999baaa292f3b02ada429113369a9f9d3c5

it used to be (f c rest) until that change

is there anyone think that in hiccup, one space for indentation make it's hard to read the structure?

@doglooksgood yeah, I think so too. I typically put newlines more often between hiccup levels when I can’t see it

However, I don’t know that I think that is the greatest style

i think a hiccup more than 20 lines is really hard to read.

i wonder how people solve this problem

One thing I do pretty often is to extract chunks of hiccup into a separate component

I think that makes it perhaps more readable anyways in some of the cases where you’d have a a lot of lines of hiccup.

maybe this is the only way

@lee.justin.m Good catch, thanks

Another thing I've been wondering is why use state/set-state at all? I have inherited a project where that's done and had to read the source to see what it does (and then more related code elsewhere...) since it's not mentioned anywhere in any docs, nor does there seem to be a single 3rd party guide or tutorial that would use them. Everywhere the state is done with a direct call to ratom bound with lexical scope

there’s no good reason i can think of to use react’s state mechanism

+1

It's not react's state, actually

My coworker mentioned that, but based on the source it's just a "random" field created on the JS object, called cljsField

It's not used anywhere else, despite the pretty generic name. And it's distinct from the state field that react itself uses

But instead of being in lexical scope, you can deref it via the JS object. Which doesn't seem to be around except in those lifecycle methods I first asked about (that this)

Both that and the ratom have seemed to exist for a pretty long time (though the state didn't use ratom internally until 0.4.0), so it doesn't seem to be a case of older idea being superseded with a better one

yea i don’t know. i did find this comment which may or may not be part of it https://github.com/reagent-project/reagent/issues/47#issuecomment-67303990