Skip to content
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

Server side rendering #31

Open
luxbock opened this issue Dec 21, 2014 · 2 comments
Open

Server side rendering #31

luxbock opened this issue Dec 21, 2014 · 2 comments

Comments

@luxbock
Copy link

luxbock commented Dec 21, 2014

It's possible to pre-render your application server side with React based wrappers by evaluating your components in Nashorn and calling rendertoString to get the HTML output.

Since Hiccup works just fine on both Clojure and ClojureScript, then it seems like doing server side rendering with freactive should be significantly easier than this. One would just have to port the key API functions such as rx, cursor and atom over to Clojure, and then add an additional function that outputs the Hiccup with everything dereferenced.

I remember that freactive started originally as a JFX wrapper, which I have no experience with. I see that this repository contains code that I assume is related to this background. Would what I'm suggesting cause some conflicts with this JFX work? Might there be some synergy in here, where one could build a JFX GUI and a web front-end sharing the same code base?

FWIW my use case would be sharing components between a Gorilla REPL and a web application. It's not urgent, but I figured that someone else is bound to end up needing this as well, so it's better to think things through earlier rather than later.

@aaronc
Copy link
Owner

aaronc commented Dec 21, 2014

Yep, it's something that I've thought of too!

I brainstormed something like this a little while ago: https://gist.github.com/aaronc/c47a79aff8862244226d

The idea is to keep Java and Clojurescript APIs close enough...

@aaronc
Copy link
Owner

aaronc commented Dec 21, 2014

Note: once you go a little further with this, it becomes clear there are some pretty important challenges that would need to be overcome - most importantly on the client you expect to have one "global state" whereas server side you're managing many clients. So (defonce global-state ...) plus a bunch of (defonce some-cursor (cursor global-state...)) will not work with this model... Not sure yet how to get around this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants