I have a universal React application. Within one of the pages I want to include some HTML from another server - Edge side includes (ESI) have been mentioned, but this methodology doesn't seem to be compatible with Universal React applications, as:
we may not be able to recreate the functionality of an Edge side include client side, at least not without revealing the external URL to the browser. I guess we could create a proxy page on our server to do this, and load the html snippet via AJAX when doing this client side, but that still leaves us with the second issue...
Using an ESI means injecting non React DOM content in to the already (server side) rendered DOM of the React application when processing on CDN server. I am pretty sure this would make the data-react-checksum invalid and I can't think of a way to avoid this.
Is there an alternative, React-friendly, universal rendering approach that could be used?
Related
I'm currently trying to understand the concepts behind SSR in a ReactJS application and cannot seem to understand one of the key concepts.
The official ReactJS documentation explains that when hydrating, the content rendered on the client must be identical to the one rendered on the server.
React expects that the rendered content is identical between the
server and the client. It can patch up differences in text content,
but you should treat mismatches as bugs and fix them. In development
mode, React warns about mismatches during hydration. There are no
guarantees that attribute differences will be patched up in case of
mismatches. This is important for performance reasons because in most
apps, mismatches are rare, and so validating all markup would be
prohibitively expensive.
This is clearly possible by sharing components between the server and the client but somehow seems to defeat the idea to do the heavy lifting on the server side.
If for example a page requires loading a large amount of data from a database to be rendered and this is done on the server side, the client would now need to load all the data over to the client just to render the exact same page and hydrate it.
What am I missing?
What is the point of server side rendering in React/Redux?
It would seem to me that another level of complexity is being added to the software, but I don't really see the benefit of it.
What are some common use cases for server side rendering?
React's SSR (Server Side Rendering) offers some benefits over CSR (Client Side Rendering):
1. Improved (Perceived) performance at the client side
Obviously, rendered components are shown to the user right away without the need to wait for browser to render. The website won't be interactive until all React code are loaded and executed, but the perceived performance is improved by showing content to users ASAP.
2. Better SEO
Since content are rendered at the server side, search engine crawlers can see the rendered content instead of just a blank page with JS tags.
Note: Google crawler supports JavaScript rendering, not sure about other Search Engines though.
Interms of complexity - yes, SSR introduced extra complexity but there's always a tradeoff for each technical decision.
The whole point of so called Universal apps or "Isomorphic JavaScript" is its "write once, run everywhere" kind of motto. Meaning that you wouldn't need to maintain a specific backend project and a specific frontend project differing in techniques and instead consolidate a whole JavaScript project into one.
It's not quite as dandy as you'd think because you still need to maintain a backend specific part that handles the initial GET request.
Furthermore you also leverage the Single Page nature of an application whilst getting the server side first page load making your website 100% crawlable by the Googs, even though Google now crawls SPAs quite competently currently.
As for complexity - it could be as complex or as simple as you would want to, I guess. Not everything is solved by doing a "Universal app" nor is everything solved by doing a standard web app either.
I am starting a new project and one of the requirements is potentially for the app to work when javascript is turned off.
I have been using reactjs for a while but solely as a SPA javascript app that runs in the browser.
I don't think I quite understand how a react SSR application works.
next.js is intriguing. Will a SSR application work without javascript?
If not can someone explain how an SSR application works or what problem it is solving.
SSR means the server will render the initial state of the application before sending it to the client on the initial run. This makes it so that:
Crawlers see actual content and can index your site based on it.
In most cases it speeds up your application since it puts the responsibility of the initial request on the server which is usually faster than most commercial computers
An SSR cannot work without javascript. It'll render initially but then subsequent executions and state changes will not be possible.
I suppose if your application doesn't require any subsequent state changes or provide further functionalities after the first load then it wouldn't need javascript.
I was going through React tutorials and on the web I saw a lot about isomorphic React. Just got confused on what it is and how it works.
My understanding is that "isomorphic React" is an application is that it loads all the data required at start-up and then it keeps rendering on the client side as per user's request, holding the complete data in store (Redux architecture).
Now what if I have a scenario like I need to load my complete HTML form using webservice from a 3rd party application where I get the data from it as a json (schema of what fields need to be rendered on the screen) and upon performing some action I need to send the request back so that I will get some other schema to load it as my next screen.
In this scenario how do I use isomorphic, as every time I need to make a server call or an ajax call (which I do not like to do as it might expose the APIs).
So in this case can I say this application as isomorphic or my understanding with regard to isomorphic is completely wrong?
Isomorphic: "corresponding or similar in form or relations".
With regard to web apps, this means that the server is somehow similar to the client - in the sense that the server is capable of rendering as much as the client. In a way, isomorphic web apps are a return to the old paradigm where the server would render data and then send it pre-rendered to the client (think PHP templates or Ruby erb).
Specifically with isomorphic React, this means that the server renders the initial HTML for the client using React components and React.renderToString(). This eliminates double work such as having erb templates on the server side when using Rails but then using Handlebars for client-side templates and also avoid the FOUC. You can just use React for everything.
Now, if you're using a 3rd party service, you'd just use the json data as usual. What would make your app isomorphic or not would be whether your own server uses the same templating engine as your front-end. Any third party services you might consume have no bearing on whether your app is isomorphic or not.
Understand Isomorphic at high level.
Server driven world : In this world, when user open a page in the browser, there are lot of interaction happened between client(browser) and server. In order to load page in the browser, the browser and server go to work by sending request and rendering to provide a webpage to the user. In this world, server was in charge of rendering each page in response to user interaction. For example; if user click on submit button then request goes to server with the data user entered in the form and in response server will return the new HTML with data to the browser to show next screen. Here server is responsible for UI too along with business logic and data model. This approach has many advantage and disadvantage.
Client driven world or Single page application world
In this world, webpage rendering responsibility was handed over to the client (browser) and server was responsible mostly for business logic and data model. This again has lot of advantage and some disadvantage.
Client side and server side rendering world each has its own benefits and 'Isomorphic JavaScript’ is the way to obtain the best of both the worlds.
And React is a framework to provide isomorphic support out of the box.
In my web app, I don't want to use hash-based routing, I don't want to see any # appear in my URLs. I want to use RESTful URLs, e.g., http://www.example.com/blog/id.
react-router can deal with client-side routing quite well, but if a user hit enter on the browser address bar or refresh the page, the request will be sent to the web server and then the web server has to understand the URL and handle the routing.
Isomorphic is a good solution to this situation since it can render any page on both client-side and server-side. Actually there are many react starter kit projects on Github which claim to be isomorphic.
In my opinion, isomorphic looks beautiful but it's too expensive to write code: you need to make you react components render successfully both on client-side and server-side, which needs developers to make great efforts.
So here is my question, can I just make the react-router be isomorphic, not the entire code?
Yes. You can use react-router for a purely front-end (non-ismorphic) app with HTML5 history.
The routing is determined client side, so react-router will spit out the expected page.
However, whilst you don't need to write any server side code, you will need to configure the web server to point your routes to the correct place. This usually means pointing every single request - or every single valid request - to the same HTML file or entry point. Exactly how you do this depends on what you're using to serve your pages - Express, Apache etc.
I hope that makes sense.