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.
Related
I am evaluating how is it possible to implement Server Side Rendering in SPA app with React and CMS as backend.
This is the approach I see Next.js suggest to have per-rendered and all most all CMS system suggests:
User request a page from react app running on Node server
Node server requests JSON data from CMS through fetch call
Then React App reads this JSON and transform HTML into String like renderToString() and sends the response back to the user.
The disadvantage of this approach is that if JSON data from CMS is huge then first request takes long time.
What alternate solution do you suggest?
Heyooo, Contentful DevRel here. 👋🏻
your concerns are absolutely valid.
And that's why Next.js just recently added advanced static pre-generation using getStaticProps. The goal is to tackle the long dynamic response times by pre-generating as much as possible. This way the user has a fast initial content paint, but can still enjoy all the dynamic benefits that come with a React application (Next.js usually follows an isomorphic JavaScript architecture)
The processing time you describe then is moved from dynamic request/response time into build-processes.
In general, when you're not dealing with millions of pages, I recommend giving static HTML a try. It makes applications often faster, safer, and more secure. For more complext and larger sites, Vercel is also experimenting with hybrid solutions that offer ways to only pre-generate certain pages. That's all very new though. :)
Using a client side routing server side doesn't forge entire page to serve a client, but datas are downloaded from webapp "on demand".
So, in this scenario, if you see html code you could see something like this below:
<body>
<div class="blah">{{content}}</div>
</body>
I know that prerender strategy can be used and i think that probably google crawler is very smarty and can see contents anyway, but the question is:
is it good this approach on seo side?
Using prerender strategy server needs to generate page with content. Could be that a penalty in page speed factor?
Thank you in advance to everyone.
As you've mentioned google is pretty smart and from a recent experience, is able to fetch some of your site's static content even when using client-side rendering. However when it comes to client-side routing it's not quite there yet so if you need to have SEO, server side rendering frameworks like nuxt.js should be your go-to.
but datas are downloaded from webapp "on demand"
The same thing applies when you do asynchronous fetches (download on demand as you've described it), imagine the data inside your {{ content }} was coming from an external API, as far as I'm concerned no crawler at this time is able to deal with this, so your content area would just be empty. So generally speaking, when SEO is an requirement, so is server-side rendering.
Using prerender strategy server needs to generate page with content.
Could be that a penalty in page speed factor?
Yes and no. Load times will certainly go up a little, but when using client-side rendering, the client needs to render the page after loading it, so this time just gets shifted to your server. This applies again to asynchronous data fetching. The delivery of the site will take longer, but the data it has to fetch will already be there, so the client wont have to do it (SSR frameworks allow you to fetch data and render it before sending the site to the client). If you accumulate everything, there shouldn't be a huge difference in time from sending the request to actually seeing the rendered page in your browser.
I've got an old app I wrote in Node, Mongo, Express and Handlebars. It seems to be a bit outdated in the sense that it was more static and all data was called locally off the same domain and rendered with Handlebars on the server side, which I thought was always necessary for SEO and it wasn't built with the idea of later building and connecting the data to a mobile version.
I've been using React a lot lately as well as looking into building mobile apps and with the tutorials out there, it seems like most apps these days are designed in a way that the backend is mostly a remote api with cross site origin requests enabled and a frontend that just gets the data from it and parses it on the frontend whether it's a desktop client or a mobile client.
What would be the best way to modernize my old app that'd keep it rendering on the server side using react instead of handlebars for SEO, while also having an api service for if I were to develop a mobile version that could get and parse the data?
There's a lot of server side rending react tutorials out there, but I'm not sure what the best approach is.
To turn your current app into a SSR (server side rendered) react application would be a big ask.
You would have more luck ripping out the html / handle bars response and just returning JSON instead, effectively turning it into an API.
In terms of adding a SSR react layer, the easiest option would be to use something like Next.JS. This does the heavy lifting for you to create server side rendering. There are plenty of other options out there but Next is one of the best and probably the easiest to get going with.
You would then make API calls from your SSR Next / React app to the Node API.
You can reuse the same API for a mobile application if you chose to go down that path at a later stage.
You would then make API calls from your SSR Next / React app to the Node API.
You can reuse the same API for a mobile application if you chose to go down that path at a later stage.
I created a web app in mvc 5, using angularjs as controller but the problem is, all my code of my app will be shown if i click on inspect in google chrome, i don't want to show my coding to any user, how can i prevent the user to view my coding,
and is angularjs is less safer then c# and is there any way (by coding) to prevent all the users to view our code in insect element
i know this is not exactly related to coding, but my app has the
transacion related to banks
This is normal with any web application that depends on client side scripting language.
JavaScript should be only used to handle the user interface flow and interactions, the business logic and persistence should be handled in the back end.
You should never trust any data coming from the UI, always validate it before retrieval or saving.
As for the code that is visible, you can always minify the JavaScript files, this will make it at least harder for anyone to inspect and understand the code
I'm thinking how to implement a SPA on Zend framework 2 using Reactjs? Haven't seen any tutorial that might help me. So, I was asking if this is possible. How would zf2 will handle the routes?
The routes are handled on the client side (by pushing URLs into browser's history so you can also use browser's back button for navigation)
Simply put, changing a route will not load a whole page from the server.
The server does not even know that your JS app is changing the URL in the browser (imagine you write by hand http://example.com#test while you were already on example.com; that #test thing is a fragment URL and it will never be sent to a server)
Instead, the JS application will respond to (once again, client-side) route changes by rendering a different page or section, and making some ajax calls to the server to fetch or update data.
Now let's see what the server should do:
send the first page (the "single-page") and the assets (CSS, JS) on
the first load
respond to app-originated AJAX API calls once the page is loaded and
the JS app has been started
That's why they call them "single page apps", because they do much of the logic and the presentation in the browser (DOM rendering, routes), and the server merely acts as a data layer, or a backend if you like this word better.