coopinabox / praxis

2 stars 0 forks source link

client / server rendering #20

Open ahdinosaur opened 10 years ago

ahdinosaur commented 10 years ago

options:

it's not necessary at the moment so i think the best option is to wait for rendr to have a complete example with full React integration and evaluate then.

derekrazo commented 10 years ago

Can you elaborate on what you mean by client server routing here?

On Friday, March 7, 2014, Michael Williams notifications@github.com wrote:

options:

  • rendr https://github.com/rendrjs/rendr
  • roll our own solution
    • use backbone-react-componenthttps://github.com/magalhas/backbone-react-component
    • use a client/server router like crossroadshttp://millermedeiros.github.io/crossroads.js/
    • send initial state down as json

it's not necessary at the moment so i think the best option is to wait for rendr to have a complete example with full React integration and evaluate then.

Reply to this email directly or view it on GitHubhttps://github.com/coopinabox/praxis/issues/20 .

ahdinosaur commented 10 years ago

the overall idea is to have an app that can be understood on the server or by the client. the benefit of a server-side app is lower "time to content", search index-able, noscript-able, etc. the benefit of a client-side app is fluid content updates and powerful interactivity. being understood by both means the server can initially render the app, send it to the client, who can immediately start interacting with the page while the rest of the code loads. very useful especially for mobile users.

React as a view engine makes this easy, instead of React.renderComponent(<Component />, domElement) we React.renderComponentToString(<Component />). Backbone has a few slight hiccups, namely that the jQuery.ajax it relies on doesn't work out-of-the-box and Backbone.Router is meant for client-side routing.

we could get past these issues with some coding fu, as it is all very do-able (i did it in my other stack example), but of course it takes a little bit of time.

in direct response to your question about routers, there are many routers that exist (a router being something that dispatches to handler functions based on paths) that work on both the server and the client. on the server, we get a path every request, setup the models and fetch the data, render the view to a string, send the response. on the client, we get a path (either initially or on path changes), setup the models (and fetch any data), render the view to a dom element, setup any listeners.

again, in the interest of spending time on more important issues, i do think it's best to leave it up to rendr which is probably going to do it better and has people to support the effort. rendr is meant to integrate Backbone apps for both the server and the client, which it does by integrating express and Backbone.Router routing into a common rails-y controller system, while also doing similar integration for other Backbone modules. support for React is in progress and when it is available the port should be straightforward.

rendr announcement post.