I've recently dived into React+Flux on the front-end, and I love it! But I want to also be able to use React on the back-end to avoid having to duplicate views and rendering logic.
I've seen that React supports server-side rendering if you use Node, but I do not use Node for my back-end logic.
So I'm wondering, can I set up a daemon written in Node that just renders HTML based on the data it receives and the root React component?
What I have in mind is to have my back-end application call this daemon with data already prepared (so that domain logic can live on my main back-end application), get HTML, and return that to the front-end.
Is this approach feasible? Has this been done before? I'd love some feedback!
I see that it's been a month and there are still no comments, I will share some of my understandings.
We can use this setup:
An API written in PHP or something similar that serves data.
Isomorphic React components - render on the server, attach event listeners on the client.
Server-side (Node) - the React component uses AJAX calls to get its props from the API and embeds them into a <script id="props" /> tag in the HTML as a JSON string.
Client-side - the component checks the script tag for props. If there is data, then it uses that to skip the re-rendering; if not (due to a server error or something), it can still use AJAX to get its props.
The main idea is that the website is isomorphic (server and client share the same code), so your existing front-end can be easily adapted to this setup.
A good place to start is a simple example about isomorphic React components. This tutorial can also provide an overview to this subject.
Related
I would like to do the initial render for my React application on the server side, but am having trouble importing and using React components without using something like babel/register (which is not suitable for production).
I would rather not have to compile my server side code for production, but would like to load an node-suitable React component to send to the client via res.send(React.createElement(Html)).
When I run this I get...
Unexpected token <
I assume this is because my components render method returns <!doctype html>...</html.
Is there a way I can have Node render a React component without having to use babel/compiling code before deploying?
Is there a way I can have Node render a React component without having
to use babel/compiling code before deploying?
No. Since JSX isn't real JavaScript, you need to transpile it at some point, either ahead of time (in a build script) or at run time (using babel-register).
Personally I ignore babel's advice to not use babel-register in production. It works just fine, I always cache + prime responses so performance isn't relevant. I'm open to hearing why transpiling with babel-register is bad though.
Short answer, yes.
this is from the official docs:
ReactDOMServer
The react-dom/server package allows you to render your
components on the server.
ReactDOMServer.renderToString
string renderToString(ReactElement element)
Render a ReactElement to its initial HTML. This should only
be used on the server. React will return an HTML string. You can use
this method to generate HTML on the server and send the markup down on
the initial request for faster page loads and to allow search engines
to crawl your pages for SEO purposes.
If you call ReactDOM.render() on a node that already has this
server-rendered markup, React will preserve it and only attach event
handlers, allowing you to have a very performant first-load
experience.
ReactDOMServer.renderToStaticMarkup
string renderToStaticMarkup(ReactElement element)
Similar to renderToString,
except this doesn't create extra DOM attributes such as data-react-id,
that React uses internally. This is useful if you want to use React as
a simple static page generator, as stripping away the extra attributes
can save lots of bytes.
However, if you want to use JSX you have to use babel, otherwise, you can use Reacts JS Syntax.
Here is a link to an example:
https://github.com/mhart/react-server-example
I have an application which uses nodejs as server and backbonejs as the frontend framework. As I know, both backbonejs and nodejs handle the url.
I have a question: for example, let say I have page called localhost/project and a page called localhost/details. When I load either of these pages, nodejs server should be called first, and then in the view.jade I have:
script(type="text/javascript", data-main="/js/bootstrap", src="/js/lib/requirejs/require-min.js")
which initiate the control of backbonejs. So, does that mean everytime that I load a NEW page (localhost/details --> localhost/project), I have to reload all the steps for initializing the backbonejs (requireJS work)?
Unless you have to do it differently, perhaps a better approach would be to use node.js as a REST API. I would use a framework like express. Then, in your Backbone code, hook your model and routes up to call your node API and update the views with the data it receives.
Unless you are doing any kind of processing on the server side, you can skip the node step and run your SPA's right off of Firebase or Parse.
I'm building a web application using node.js, this is my first time working with node. I'm using express framework and I have a question about client side rendering.
All the tutorials that I have found online talk about express and server side rendering. They talk about how you can use jade the express templating engine, to serve rendered templates as reponse to your web application.
My application is going to be client heavy and most of the rendering will be done client side. I want to call server to just get plain JSON response and then render it client side, so server side rendering is not of much use.
In this case, is express a right choice? I really like the way I can write APIS in express but I'm concerned about how to serve my application. If I don't want to use the server side rendering it would mean that I would have to serve static HTML at the first call which seems weird to me.
You might want to try Emberjs if you want most of the work done on the client side. But still, you need to send the data to the client so one way is to build your app totally on the client side just by sending a plain html and working your way up there. You can also precompile jade
What you are describing sounds like you are searching for an javascript MVC(or other) solution.
There are a lot of possibilities. Take the right tools for the right job.
Try the following link to get an nice overview of what is possible.
Helping you select an MV* framework
I am working on a single page web application and have run into a question for which I cannot seem to find the answer.
Is there a way to load partial views from server side when using angular? I am using nodeJs, with express and Jade, and wanted to load partial views into angular, but I am confused on how I would do such. Is there any particular guideline that I should follow to structure my files?
I do not want to load all of my partials from angular, so I wanted to know if there is a way to load the views in from node.
EDIT: What I mean to ask is, am I allowed to load in partial jade views on angular? Does that have any effect on the way the page renders?
You can't. Angular is a Single Page Application framework, it means that you application (ie HTML+CSS+JS) is loaded once at first load in the browser, and all what happens is a communication of raw data (JSON over REST for example), Angular is in charge of displaying correctly the already-loaded-html correctly according to these raw data.
I'm looking into solutions for integrating Ember.js with Node.js+Express+Tower.js.
I just started looking into Tower.js (the last couple of hours), and it looks like that the framework provides a nice structure for placing both server-side and client-side code (similar to the assets folder in Rails).
Since everything is in Javascript, I could either place Ember application code:
Entirely on the client, i.e., send everything on first request.
Serve only what is initially needed, and serve the rest only upon request.
In the 2nd solution, one could render the views on the server and send pure HTML.
Also what about the application logic of Ember (controllers, models, states, ...). How can it better be integrated with server-side Javascript (e.g., node.js+Express+Tower.js), so that
repeated code is minimized. In an ideal scenario, you define each model/controller/etc once and its used both on the server and on the client.
We are integrating Ember.js into the core of Tower.js, this has been planned from the beginning.
https://github.com/viatropos/tower/blob/development/test/cases/support/emberTest.coffee
Not quite there yet. But it's happening next.
Ember currently works in Node.js and the Browser, as does Tower. Controllers on the server will work like Rails' with web socket additions. Controllers on the client will work like they do on the server and like with Ember, with web socket support - still fleshing this out.