Clojurians Log v2

hello, currently the helix.dom namespace only provides macro versions of the things, I’m having a problem with this, because I can’t use apply to spread children (for cases where I don’t have a key for each item), so I can’t do something like this in helix:

(defn spread-component [& children]
  (apply dom/div "Some default stuff" children))

(spread-component (dom/div "no need") "for keys")

@lilactown what you think about doing like Fulcro, and also providing fn versions for the DOM building blocks?

for anybody else with this problem, this is a current possible workaround:

(defn spread-component [& children]
  (apply h/create-element "div" #js {} "Some default stuff" children))

(spread-component (dom/div "no need") "for keys")

I'm not opposed to fn versions of the DOM as well, but it's not something I run into very often

spread-component here isn't a component but rather a builder function - it doesn't get any of its lifecycle attached to it because you're calling it like a function

the "proper" helix/React way of doing this would be:

(defnc spread-component
  [{:keys [children]}]
  (d/div
    "some default"
    children))

($ spread-component (d/div "no need") "for keys")

this shouldn't give you warnings about keys because we're passing the opaque children data structure to React, and it is already technically keyed

interesting, I didn’t knew about this children trick

but still, when there are case that we need to map over some collection and than splat, apply is still needed, I’ll see if I can get some time and try to add this to Helix

I don't think apply should ever be needed

if you have an actually dynamic list of children, you should key them

if you're mapping over children, you can use helix.children/map and pass in the resulting children into the component

this feels like you're trying to use components as functions, which they are not

React accepts partial applications though functions, and I see many patterns using it, and to me feels very natural, I understand the trade-offs, and in many cases to me the application makes sense

the issue to me is that the usage of a language construct (macros) is limiting the usage that otherwise is available’

but I understand your POV, and its just a small part of the library, I can always just have other dom constructs (that’s what I end up doing) 🙂

> React accepts partial applications though functions, and I see many patterns using it can you explain this more? I'm not sure I understand what patterns use it.

also, helix provides $ as a function for edge cases where macros aren't good; so (apply $ "div" {:style {:border "1px solid red"}} ,,,) works as expected. before I add more stuff to helix, I want to understand the use cases that it solves. having more stuff makes it harder when people have questions about how they should do something, to answer them in a helpful and correct way. so if I understand the circumstances when e.g. calling a component as a function, rather than constructing an element, is useful then I can add those tools and docs explaining when/why to use them

oh, I wasn’t aware that $ was a fn, I though it was macro only

that’s cool, and for that is enough, because it keeps the same prop semantics

changing the subject, one thing that keeps coming back to me while using Helix is that I tend to use a lot of namespaced keywords in my views too, and because Helix works so close to React it can’t use qualified keywords at props top level. for one side I think its nice when working closer to react libs, it makes integration nice there. but on the pure cljs side it adds friction to use qualified keywords. I wonder your thoughts on the subject

or more specifically: do you think the problem of edn props is something that Helix should handle? or its something for the users to work around (creating abstractions on top of the Helix)

helix should be able to accept namespaced keywords as top-level props

if it's not working then I would consider that a bug