Fork me on GitHub
#helix
<
2021-04-14
>
wilkerlucio16:04:16

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

wilkerlucio16:04:41

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

wilkerlucio16:04:08

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

lilactown17:04:12

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

lilactown17:04:48

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

lilactown17:04:44

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

lilactown17:04:35

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

wilkerlucio17:04:46

interesting, I didn’t knew about this children trick

wilkerlucio18:04:02

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

lilactown19:04:05

I don't think apply should ever be needed

lilactown19:04:37

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

lilactown19:04:35

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

lilactown19:04:47

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

wilkerlucio19:04:32

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

wilkerlucio19:04:59

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

wilkerlucio19:04:44

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

lilactown19:04:02

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

lilactown19:04:29

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

wilkerlucio19:04:47

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

wilkerlucio19:04:06

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

wilkerlucio19:04:08

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

wilkerlucio19:04:28

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)

lilactown23:04:46

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

lilactown23:04:51

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

wilkerlucio14:04:46

ha, it always accepted that? I’m feeling like a crazy person, getting all the things wrong here, haha, thanks man, its working great 🙂