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

Define recipe for a server-side render #14

Open
cdaringe opened this issue May 8, 2021 · 1 comment
Open

Define recipe for a server-side render #14

cdaringe opened this issue May 8, 2021 · 1 comment
Labels
forwarded-to-js-devs This report has been forwarded to Jane Street's internal review system.

Comments

@cdaringe
Copy link

cdaringe commented May 8, 2021

Problem

examples/ have excellent content for defining client side applications. I am interested in the classico isomorphic SSR + hydrate/re-render in browser paradigm (e.g. next.js), and it seems like a well defined set of function calls in the incr_dom world could enable this.

  • server: (psuedo code), on GET /my-sweet-page => MyServerImpl.html @@ H.show (App.render model)
  • browser => Start_app.start (module App) ...

There's clearly more involved here, but OCaml community I don't think has a killer solve for this yet, even though all of the capabilities are there. Additionally, I do see that there's some work going into bonsai ATM by incr_dom contributors. Aside, should incr_dom users continue to expect development here, or really only be expecting new work (maintenance, features, etc) to be flowing from that project?

Thanks!

@github-iron github-iron added the forwarded-to-js-devs This report has been forwarded to Jane Street's internal review system. label May 10, 2021
@TyOverby
Copy link
Member

At the moment, it is not possible for any Incr_dom content to be rendered serverside because the virtual-dom library that we rely on is javascript-only. We are planning on making a pure-OCaml version replacement though, so that might become an option sometime in the future.

Additionally, I do see that there's some work going into bonsai ATM by incr_dom contributors. Aside, should incr_dom users continue to expect development here, or really only be expecting new work (maintenance, features, etc) to be flowing from that project?

That's correct, Bonsai is built on top of Incr_dom, so changes to Incr_dom nowadays are largely going to be due to requirements for Bonsai. Incr_dom is maintained, but also quite stable. Most of the improvements that I've wanted to make it were of the form "this boilerplate shouldn't be necessary if the right abstractions were in place", which is what the Bonsai project is all about.

Hope that answers your questions!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
forwarded-to-js-devs This report has been forwarded to Jane Street's internal review system.
Projects
None yet
Development

No branches or pull requests

3 participants