I am using Reactjs, webpack along with page.js (routing) to build a webapp. Webpack gives me a bundle.js which is loaded on the client side.
I found out the og Meta tags can't be crawled if I am loading them on the client so, I have to implement it on the server side (server side rendering). Is there any way to implement it ?
(I didn't find proper documentation about this on net).
A lot of people are rendering the "shell" of the html with another template language on the server (since only the server needs to render it). You shouldn't use React to render stuff outside the body using normal APIs (there are known issues with that). However you can use renderToStaticMarkup, which I think is a nicer way as you are not introducing another template language on the server just to render the shell.
Of course this means that you can't update something like the meta description or document.title in a normal React way, you would have to just do it with plain old JavaScript. Alternatively I recommend react-helmet (which can modify the meta and title when the server renders too).
I made an example here which may be helpful - https://github.com/DominicTobias/universal-react/
Related
The project is using EJS, Express/NodeJs, MongoDB and I have added ReactJs to it.
Now I want to implement Webpack for bundling EJS and ReactJs files together.
The project eventually has to be converted to ReactJs but for now we need to Bundle EJS as well.
Is there a way I can do that? I need help.
EJS can run client-side and React can run server-side but a typical Express/EJS set up runs the EJS server side and delivers plain HTML to the client, while a typical React setup runs the React code client-side (and might add server-side rendering as a bonus).
Assuming you aren't doing anything highly atypical (in which case you really need to explain your setup in much more detail) then the short answer is: No.
You need your EJS to run server-side, so putting it in a bundle and sending it to the client is pointless.
If you want to transition from a classical server-side rendering of HTML to a React system then a typical way to do that is on a page-by-page basis. \
You can either serve up a basic static bootstrap HTML document for the pages you replace, or get creative with a SSR system for those pages (and either do some clever mixing of routing rules or just put a reverse proxy that diverts different URLs to a Next.js server or an Express server depending on if they have migrated or not).
Another approach is is to write a series of small React components that replace individual components of pages (e.g. a navbar application) and have the entry point include multiple ReactDOM.render calls for each component.
That latter approach is less suited to involving SSR at all though.
Either way: You wouldn't be sending the server-side EJS code to the client so it wouldn't be bundled with the React code.
I am using react-markdown (escaped) to load markdown from a JSON file.
I utilize a static site delivers on CloudFront to cut cost and remove the need of operations costs on servers.
Currently all posts get compiled into a posts.json file that get read by react-markdown in a react-based static site.
Beyond maybe chunking this to into multiple files to prevent a huge json file needing downloading, is there any kind of issue from this method?
Is this a bad idea?
EDIT; react-snap is being used to "prebuild" or whatever the term may be. I however am unsure if this is doing anything in regards the json that gets loaded on the page, for example if its getting output in build as plain HTML. Will have to confirm.
Your approach does take on some overhead and latency since there are several dependencies that must be satisfied before your content reaches the user.
The browser must load and parse the script
The script must fetch the JSON from the server
react-markdown has to parse the markdown strings
React has to render the components
None of these are likely to be particularly slow, but we can't do any of it concurrently, and it adds up.
But since your markdown is static and doesn't require re-rendering, you can get some efficiency from moving the render to the server, possibly even to the build step itself. If the markdown string is compiled to HTML via react-markdown at build time, then the client receives the markup that much more quickly.
Frameworks like Next.js do this by design - it allows you to specify async functions that fetch the data needed to render the page at build time. The data can of course be anything that is representable as React props, including JSON.
It may be neither your reponsibility nor your preference to change your project to use a new framework, but I hope the general ideas are useful on their own.
I think server-side rendering will help in your case as most of the resources need to be compiled on the client machine. you can also use a chrome puppeteer that is headless chrome that can be used to transpile resources on the server and then send it client to reduce the latency. Refer https://developers.google.com/web/tools/puppeteer
It looks like you have everything you need to use a static site generator like Gatsby. A static site generator will allow you to keep your big JSON file which will only be read on build time. A static site generator like GatsBy will help you generate stand alone static HTML documents for each of your blog post.
You also can host your static site for free on any the popular CDNs free tiers like Nelify and Surge
Because all Angular & React does similar type of templating behind the scene. So why use ejs..? Is that for project that do not use Angular/React and alike.?
React and Angular are tools initially built to create Client Side applications or Single Page Applications. This means that the client receives a single HTML file and one or more JS files that contain the app's code. All of the HTML that you then see generated in the website is actually built in the client (AKA the user's browser).
We now see both React and Angular being used for aplications that have their HTML built in the backend, either in run time (Server Side Rendering) or on build time (technically also Server Side Rendering but usually referred to as Static Site Generation, see Gatsby for an example).
EJS is a simpler tool, it basically just gets an HTML file (with the .ejs termination) and some placeholders {{data}}, and fills these with anything that we might want to use. What basically happens when you generate an HTML page to send to the client when using EJS is something along these lines:
index.ejs -> (In Node) Pass object with data values for placeholders -> Replace placeholders with actual values -> Output finished HTML file with value instead of placeholders
Notice that there is no special logic, state or any other complexity that you may find in a React or Angular application. It is a templating engine, it just does what was described in my snippet.
I am starting to play around in React and I noticed that the simple app I am making is all in JS. My html page is only an empty body tag!
So I had a few questions because I am new to this framework.
Is my whole app supposed to be essentially all JS?
If it's not supposed to be all JS, when do I decide that something belongs in my html file vs creating it as a react component in JS?
What are the benefits / disadvantages that my html is in all JS?
Am I supposed to set up my server to compile the JS to html to serve html re: Server Side Rendering to maximize performance benefits?
React brings a new way of seeing things: components.
There are two approaches when using React:
AMD (Asynchronous Module Definition): your javascript files are loaded under demand; https://en.wikipedia.org/wiki/Asynchronous_module_definition and in http://requirejs.org/docs/whyamd.html
CommonJS: in this case your app is bundled into only one file (or a few 'chunck' files) - it seems that people have been preferred this way because the app is loaded only one time and it goes to the server only for loading and writing data (i.e. JSON); it helps in reducing charges over the server;
The page is really an empty body tag.... hehe
But with some considerations:
Please take a look at React-Router (or even Angular Route if you use AngularJS):
To move from the current 'page' (view) to a new page, the browser's URL is 'pushed' (changed) without going to the server and the entire new page is mounted according to that URL. This is made by React-Router or Angular Route.
Yes, you are supposed to make your server to output html: you can search for Isommorphic Javascript if you want your client html to be mounted dynamically (useful when you need search engines like Google to scan your page) More info at: http://isomorphic.net/ and this can help you: https://strongloop.com/strongblog/node-js-react-isomorphic-javascript-why-it-matters/
I know there is a lot of new technologies to study, but it's worth...
A little tip I can give you is looking for "Flux". It's a design pattern that helps structuring your application better, that allows you to scale and grow it.
You can take a look at webpack and babel too. Great stuff!
Hope this helps you.
Almost all guides available online talk about working with JSON that is fetched from the server. We are taking an alternative approach to this.
We are generating HTML markup with the data server side, at least on initial page request (mostly for SEO reasons), and then trying to get Backbone.js to takeover from there (for infinite scrolling, or making future POST requests, as an example), a la Twitter.
I have searched online for some guidance on this for over two days now but have not found anything besides this:
SEO And Accessibility With HTML5 PushState, Part 2: Progressive Enhancement With Backbone.js
Am I missing something very obvious or is there a truly clean way of doing this with Backbone and/or Reactjs?
If you're using React, I recommend react-quickstart.
The tools it comes with make server-side rendering very simple, and the client picks up the DOM and makes it interactive.
A minimal React project template which combines:
react-router-component to provide HTML5 History routing and navigation
react-async to create "asynchronous" React components
express to serve pre-rendered React components, assets and provide API
browserify to provide module system for a browser
npm to install and manage server-side and client-side dependencies