Open galdolber opened 10 years ago
+1 I could really use this! Important enough to me that I am tackling it myself but I have limited experience with CLJS and Reagent so it will take sometime.
Not sure how idiomatic it is but I have a working solution in a custom-tags branch on my fork. https://github.com/k2052/reagent/commit/9a6ab3ba9a833868148aeb9a98e1d1a77ed43da5
Seems to not have broken anything (all tests still pass). Will make a PR as soon as I have some tests written and work out the most idiomatic API.
@k2052 any word on a pr? :)
This is an even bigger deal for react native. I'll prepare a PR
@galdolber :+1:
Is there any progress on this? Is there something holding the integration of the MR back?
We also need to render hiccup that was generated elsewhere and it would help a lot.
@holmsand this seems like it would be a nice addition.
Yeah this would be pretty rad! :+1:
Any update on this PR?
I don't yet understand why this is needed.
First comment mentions server-side rendering, but in that case, the app would be rendered as string to HTML, which wouldn't refer the component functions? What use case there is for sending hiccup from server to client?
What about ReactNative? Obviously Reagent already works there, what would this improve on that environment?
I'd prefer not introducing new abstractions, especially one with global state (atom), without good reason.
@Deraen Let's say your server prepares some content that can be generated server side, like prepared info pages that are cached, or content from a CMS, and that content is supposed to contain some interactive elements, then having the ability to just send data amd render that is much nicer than having to perform a clientside postprocessing step that walks the entire tree and replaces keyword with functions.
We currently do the latter and it is super messy :/
This feature would be very useful for me!
While I didn't mention this in Clojurist Together plans directly, I have some ideas on implementing this:
[As this affects how Reagent turns Hiccup to React elements and components,] I have some ideas on allowing users configure the Reagent Hiccup compiler, similar to what Hicada does. This would also allow introducing optional features which would break existing Reagent code, by making users opt-in to these. One case would be to make React component interop simpler.
This configuration will probably allow providing a function to convert keywords (or other values) to React elements, which will allow users to configure custom tags.
When doing server side rendering, to use components you have to manually traverse the generated html and enhance the special nodes, as you cannot return a reference to a fn from the server.
Example: (defn my-component [n] [:span (str n)])
Returned from the server: [:div [:my-component 3]]
From there I manually scan it and replace :my-component for the fn reference.
Something like this would solve the problem and avoid to scan: (r/register-component! my-component :my-component)