CLJ render-to-string

[lilactown]

I'm a bit wary to support this but I see it's benefits, especially when wanting to play with component trees at a REPL.

I honestly think that Node.js will eventually have a much better story once SSR Suspense hits, but in the meantime this can cover a number of use cases.

The trick will be making sure that CLJ rendering == Node.js rendering, and supporting hooks.

[DjebbZ]

I was going to open this very issue :)

I'm interested into using hx to replace rum, in an isomorphic setup Browser/JVM. I'm talking about a real-world website that makes millions of views per day. The problem with rum is that it deviates too much from React.js, especially since the introduction of hooks.

If you want help with that:

1. I can provide, time permitting, tests, code reviews and maybe patches!
2. Look at what rum does in its test suite: it renders rum code to string, then compiles the same code with node.js and compares the output (basically just a =). I think it's a viable strategy.
3. I haven't check all hooks, but useState in CLJ could just return the initial value and use it to render to initial HTML string. Will be happy to investigate with you the problem space.

My advice, if you permit: keep the layer that hx brings on top of React.js as thin as possible, don't create unnecessary abstractions, or even don't create abstractions at all, and hx would be a killer library that stays as close to React.js as possible, especially since the design of React.js is still a giant real-world WIP. Too dangerous to introduce abstractions that could deviate any time React introduce novelty.

Thanks for reading me!

[pepe]

@DjebbZ well said. Even as I am pursuing the pure cljs way, This has value.

But the question is if it should be part of the core library?

[DjebbZ]

The good thing with a CLJ implementation is that it doesn't affect the CLJS side of things, so hx could very well handle both CLJ and CLJS server side rendering. Basically, if you follow the rum way (a very well written code base) you need: - separate CLJ and CLJS namespaces - same "wrapper" API to hooks, like `use-state`: on CLJS it just delegates to js/React.useState, on CLJ it just returns a pair of initial state and `identity` ( I think it works well) - other hooks may be no-op on CLJ side, not sure, haven't studied them thoroughly and not an expert at this point - CLJ side just needs to provide a render-html function. Basically what rum does, the code is good and fast (with the help of Java String Builder pattern to avoid unnecessary allocations of String objects on the JVM. Of course the CLJ side could need some evolution depending on the state of Suspense and other new react features. But as long as it provides the same HTML as the equivalent JS, no problem I would say. Does it sound good to you? Or what problems do you see that I didn't?

…

On Fri, Feb 8, 2019, 10:02 PM Josef Pospíšil ***@***.*** wrote: @DjebbZ <https://github.com/DjebbZ> well said. Even as I am pursuing the pure cljs way, This has value. But the question is if it should be part of the core library? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEt3n3-gS1kvDl2I1ZwzgJfoty7SgP1ks5vLeXUgaJpZM4ZN3vq> .

[lilactown]

The problem I see is that you wouldn't be able to use any 3rd party Hooks or components which are included from JS-land. I'm also not at all interested in implementing streaming rendering in CLJ, which Node.js SSR will eventually support with React Suspense.

This means that you have to separate your code base between which components and hooks are OK to use on the server vs. client-side only. Perhaps this is OK, since you could use reader-conditionals to ensure this happens. It just might be surprising.

Overall it might be a lot of work and enforce certain restrictions on the user's code that I'm not sure is worthwhile. I am listening though and will continue to consider spending some time on it in the coming weeks.

[DjebbZ]

Well, you could use JS hooks/components/whatever in pure CLJS components. Same story than rum (or even better since hx components are just React components). Then it's up to the users: if they opt-in server side rendering on CLJ, well of course they can't use them directly. In our rum code code base we used a reader conditional to make React Transition Group work just fine. Regarding server side streaming, it doesn't require only support from React: the webserver has to support it. Express.js accepts node.js streams as responses. Nothing prevents someone to just use (hx/render-html) in CLJ side and not supporting streaming. In react, you have a separate top level API to render to stream https://reactjs.org/docs/react-dom-server.html#rendertonodestream. It means it can be implemented in hx after it ships in React itself. No conflict with render-html. And if there's no interest from you or any hx users, nobody suffers from the lack of it.

…

On Sat, Feb 9, 2019, 12:01 AM Will ***@***.*** wrote: The problem I see is that you wouldn't be able to use any 3rd party Hooks or components which are included from JS-land. I'm also not at all interested in implementing streaming rendering in CLJ, which Node.js SSR will eventually support with React Suspense. This means that you have to separate your code base between which components and hooks are OK to use on the server vs. client-side only. Perhaps this is OK, since you could use reader-conditionals to ensure this happens. It just might be surprising. Overall it might be a lot of work and enforce certain restrictions on the user's code that I'm not sure is worthwhile. I am listening though and will continue to consider spending some time on it in the coming weeks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEt3rhAcHvt9Bh6jOE-jObmSB0HEaj5ks5vLgHigaJpZM4ZN3vq> .

[pepe]

Sorry for the delay.

For me it is mostly project focus, and I am not at all opposed to this idea, nor I have any say in this. Actually sorry for the noise.

[DjebbZ]

Sure, it's all up to @Lokeh. Maybe he'll consider this feature useless for his use case, or too complex, or too whatever.

[lilactown]

What I've done to move the needle on this is completely decouple the hiccup parser from React. The API now is like this:

(def hiccup-config
  {:create-element create-element-impl
   :is-element? is-element-impl
   :is-element-type? is-elemene-type-impl
   :fragment fragment-impl})

(hx.hiccup/parse hiccup-config [:div "Hello, hiccup!"])

This will use the functions provided in the hiccup-config map to transform the tree.

In hx.react, these map to react/createElement, react/isValidElement, etc.

I have pushed a proof of concept HTML string renderer in a separate branch: https://github.com/Lokeh/hx/blob/html/src/hx/html.clj

This would allow someone (either this library, or even an external library) to leverage hx.hiccup for hiccup parsing and implement their own "engine" to generate HTML strings, cljfx maps, or whatever you want while sharing the same hiccup syntax as the hx library.