Why defnc bean property is not interoperable with helix.dom ? https://gist.github.com/geraldodev/ca7954d3ee9c0e7f98862d7c49ca694c . I was trying to make an Input with some logic so I had to receive props and pass to d/input

@geraldodev I think if you use a symbol, it's assumed to be a JavaScript object, for performance reasons. You'll need to convert it to a js structure yourself using clj->js. I think bean will support that.

@dominicm helix converts it to a Bean. I tried beans ->js with no success. Also tried clj->js after your suggestion. Same result.

Hey everyone, I got an idea in my mind, though I'm not sure I fully understand `core.async` , I was thinking that I could use `channels` as reducers to an `atom` or just a `map` which then could handle multiple requests to change the state more gracefully, does this make any sense? (for some odd reason this channel seems more active than the #clojurescript channel)

@geraldodev your code is slightly incorrect, @dominicm is right that you can’t hand a symbol as props without some additional syntax: https://github.com/Lokeh/helix/blob/master/docs/creating-elements.md#dynamic-props

your example would be (d/input {:& props})

Ah, if there's ambiguity it's assumed to be a react element.

It would be handy if I could override that if I say "I know what I'm doing", e.g. I have a custom ->js that I know is fast.

sure, you can do that using either :& or &

Isn't :& dynamic & for cljs though?

you can give the & prop a map or a JS object as of the latest version

Oh, cool :).

it does a check to see if it’s a map and if not, merges it with static props using goog.object/extend

@lilactown every call that does not use literal props needs to to use :&. Is that for performance reason ? because $ needs to compile its arguments to get as much as performance as possible ?

Yep