-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why shallow-clj->js? #20
Comments
hx makes no distinction between components defined in CLJS and components defined in JS. If a component accepts JS objs/arrays for certain properties, you'll need to ensure you pass them in as such. Otherwise every component defined in hx would need to recursively convert all props to CLJS structures (or use interop). You would lose metadata and benefits like easy memoization of components. If you're doing quite a bit of interop, you could create a wrapper component that calls |
So even for CLJS components, their props are passed through |
Yep, even for CLJS components, their props are passed through See: hiccup.cljs#L39, utils.cljc. This is why you can use React components and CLJS components with exactly the same syntax; there is no distinction between them when parsing hiccup, and I don't see this as a problem; it is a tradeoff. Most components in CLJS projects are written in CLJS; If it helps, here's an HOC you can use to skip some of the boilerplate: (hx.react/defn with-edn [c]
(fn WithEdnHoc [props]
(hx.hiccup/make-node
c
(-> props hx.react/props->clj clj->js) ;; deep conversion to JS
(.-children props)))) ;; pass in children separately |
So in something like reagent this is explicitly only done when using |
Yeah, I've thought about ways to "tag" components that were made with hx to differentiate them so I could do more optimizations. But it's always going to be leaky. At the end of the day, only the dev can know what kind of props a components needs at runtime in a dynamic language like CLJS. |
Just my 2 cents. It bothered me a little at the beginning, mostly for "ideological" reasons. Now I am more happy with this approach, cause the interop with js stuff is so much easier. |
It would be nice to not have to call
clj->js
myself when passing in values to React components.I assume
shallow-clj->js
is just a performance optimization? How significant is it?I've found myself several times now wanting to pass a Clojure object into a React component and having to wrap it in a
clj->js
.The text was updated successfully, but these errors were encountered: