So, I have been searching everywhere and can't find any hints on this.
I have a REST API built with express that will be consumed by a website and in the future a mobile app.
I have to build the website and want to use react/redux, and I'm struggling to understand how to avoid the initial state to be render from server because I will have nested components and a lot of async data, and it will become a mess to maintain code both client- and server-side. Is there any solution/alternative for this?
Thanks in advance.
You don't necessarily need server-side rendering to solve this problem. You can make your components load with a blank state and then immediately fetch your data.
According to the React docs, your ajax requests should be made in the componentDidMount() lifecycle method, which fires once as soon as your initial render is complete.
If you want to ... send AJAX requests, perform those
operations in this method.
For example, you don't load your app if a user isn't authenticated, or you put up loading spinners to indicate that data is being fetched.
Related
I am coming from the world of SPA's and REST/GraphQl API's. Now I am building personal project with Next.js library for SSR(Server Side Rendered) React App.
Since I used Redux in all of my single page Apps, I'm now wondering how should I manage user state when every route user visits, a new link is loaded and the page has been refreshed.
I found some info about sessions and cookies, but neither of those are familiar to me. I looked at some online articles about using Redux with Next.js but it seems complicated.
Let's simplify how Next works, browser sends a request to the server, Next renders on server side, returns an html, then, Next re-hydrate the page, and from now it behaves as SPA.
Next has an example folder basically for every technology including redux.
Checkout the redux example.
If you're used to doing it in a route-based way, this may help understand:
the whole app (_app.js) is wrapped in the Provider for redux, so all pages and components in the app can access the store.
according to the docs:
otherwise different user data can be mixed up. On the client side the
same store is used, even between page changes.```
So your app will recreate the store on every request, but pass the request, the url, and possibly even the results (of the request) into the initial state of the store, so each page and component can utilize the store before rendering.
also checkout getInitialProps which will perform some sideEffect before the components on a page renders, and provide data to the page's props.
some resources:
https://github.com/zeit/next.js/tree/canary/examples/with-redux
https://medium.com/#bhavikbamania/a-beginner-guide-for-redux-with-next-js-4d018e1342b2
What I would like to know is, how do you built your web application? I'm really confuse as which method should I use for my project.
Already decided which technologies to choose.
1) Node.js and express as its Framework
2) MongoDB
3) React + Flux
But the problem right now, should I use method (A) or method (B)
Method (A) - Serverside rendering for HTML
app.get('/users/', function(request, respond) {
var user = "Jack";
respond.render("user", { user: user });
});
Method (B) - Clientside rendering for HTML
app.get('/users/', function(request, respond){
var user = "Jack";
respond.json({ user: user });
});
Method A will render the HTML from the server and as well as the data.
Method B will just respond the data that is needed for the client which is React.js, so that it could manipulate the data.
My concern, is which method should I use? most startups use which method?
Thank you.
It's not an either/or proposition.
React is a client side framework. You have to render on the client side. The question is whether to render on the server side in addition to rendering on the client side.
The answer? If you can, YES!
You will get SEO benefits and an initial performance boost by rendering on the server side. But you will still have to do the same client side rendering.
I suggestion googling "isomorphic react" and doing some reading. Here is one article on the subject.
http://www.smashingmagazine.com/2015/04/react-to-the-future-with-isomorphic-apps/
Well, it really depends on which vision you have on the modern web, and what you are willing to do.
Will you prefer to let your users wait, displaying a loader while data are loaded asynchronously, or will you prefer to keep your users busy as long as you can ?
Here are different articles that will help you clear your mind and be aware of the different advantages that you can have by doing server-side rendering, client-side rendering having multiple issues.
You can see this post from Twitter blog saying they improve their initial page load by 1/5th to what they had before, by moving the rendering to the server:
https://blog.twitter.com/2012/improving-performance-on-twittercom
An other article, this time from airbnb, describing the issues you can have with client-side rendering itself:
http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/
There is also an other interesting article talking about client-side/server-side rendering, bringing a debate on when should we use / not use server-side or client-side rendering and why:
https://ponyfoo.com/articles/stop-breaking-the-web
And to finish, I can give you two more link more focused on react, and describing in which way server-side rendering should be helpful for your case:
https://www.terlici.com/2015/03/18/fast-react-loading-server-rendering.html
http://reactjsnews.com/isomorphic-javascript-with-react-node/
Now, about what you SHOULD do, it's a matter of what you exactly need to do, to my opinion, but basically, you can do both at the same time (client-side AND server-side), to have the best user experience.
This concept is called "isomorphic javascript" and it is getting more and more popular these days.
The simplest architecture is to just do dynamic html rendering on the server, with no Ajax, and with a new HTML page requested for pretty much any client click. This is the 'traditional' approach, and has pros and cons.
The next simplest is to serve completely static html+js+css (your React app) to the client, and make XMLHttpRequest calls to webservices to fetch the required data (i.e. your method B).
The most complex but ideal approach (from a performance and SEO perspective) is to build an 'isomorphic' app that supports both approaches. The idea is that the server makes all the necessary WS calls that the client would make and renders the initial page that the user has visited (which could be a deep-linked part of the application), a bit like option A but using React to do the rendering, and then passes control to the client for future DOM updates. This then allows fast incremental updates to the page via web-service calls as the user interacts (e.g. just like B). Navigation between different 'pages' at this point involves using the History API to make it look like you're changing page, when actually you are just manipulating the current page using web-services. But you you then did a browser refresh, your server would send back the full HTML of the current page, before passing control to client-side React again. There are lots of React+Flux+Node examples of this approach available online, using the different flavours of Flux that support server-side rendering.
Whether that approach is worthwhile depends on your situation. It probably makes sense to start using approach B (you can share the your HTTP API between mobile apps and websites), but use a Flux architecture that supports server-side rendering and keep it in mind. That way, if you need to improve the performance of initial page loads, you have the means to do it.
Looking for some thoughts and feedback on making async requests from dust.js template helpers:
Dust.js can make async requests from template helpers, but is it actually a good idea to make use of them? Consider this scenario...
A particular page requires several api requests to be rendered. In the page's route controller, a single async api request gets the bulk of the data for the page and passes the data to the template to be rendered. In the template there are several reusable and standalone dust helpers (can be dropped in on any page) that make their own async requests in order to display their components.
In this situation, all the dust helpers have to wait until the request made from the controller finishes before their calls can be made (when template rendering begins).
It seems that ideally (excluding having one endpoint for all data on the page) all requests should occur in the route controller in order to avoid synchronous calls, otherwise the request chain would be 1) controller requests 2) dust helper requests 3) nested/dependent dust helper requests.
Cons:
route controller complexity by calling n services to build the view model
adding display components to new pages require changes to controller and template instead of just adding a template helper
Pros:
reduce/eliminate synchronous requests and increase performance
easier to understand the view model
What are your thoughts? Thanks!
If you consider to use your templates only server side I would move everything into the controller. I like to have a controller who "controls" all the data needed for the view layer.
If you think about using dust templates in the browser (so ajax calls from the cleint) both ways in my point of view are reasonable from an architectural view.
But I would ask my self some question about user experience before deciding:
How much time would take to complete all the calls from the
controller? Sometimes is better to send partial data to the user and
give to him something to view and load other components later for a
better user experience. But if the overhead is not over some ms, I
would decide to build my page context all in the controller.
Where is the data displayed in the page? Do you need it in the first
part of the page? Or user should scroll to view other sets of data?
If the data is not consumed immediately I would decide to leave it
to the client.
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.
I am learning about backbone, and from the examples and tutorials I have gotten this impression:
The initial GET / returns the skeleton page with backbone and the view templates.
Backbone uses the REST API to flesh out the page by GETting the data it needs and adding it into the DOM.
This works, but it seems wasteful in terms of additional HTTP requests, and latency from the perspective of the end user (minimum two round-trips before the page is visible. Actually three in my case, since the API must first ask which widgets are available, and then fetch the details on any available widgets....).
Is there an established, standard method for getting around this? My current candidates are:
Ignore the problem.
Embed the initialization data directly into the original page via inline javascript.
Render the page as if backbone didn't exist. When backbone finishes initializing, it will (hopefully) be in sync with the page as the user sees it. It can correct anything it needs to if things changed in the intervening couple seconds, but at least the user is not left hanging.
Another solution I haven't thought of?
Is there an established way to do this? Is it situation-specific? I am using Node / JS / Express.
Update: I think I found a solution, possibly the "accepted" solution, in Backbone's documentation:
Here's an example using reset to bootstrap a collection during initial page load, in a Rails application.
<script>
var Accounts = new Backbone.Collection;
Accounts.reset(<%= #accounts.to_json %>);
</script>
Calling collection.reset() without passing any models as arguments will empty the entire collection.