If I have a movie search application and am using ReactiveSearch with Elasticsearch. I'd like to integrate Server Side Rendering (SSR) into the app but am trying to make sure I understand implementation first before I start.
I want my Autocomplete component to be the home page of the website and I just want to render the search box as quickly as possible. I don't necessarily want to render results within milliseconds of user coming to the page - I just want to show them them content quickly.
Do I need to implement SSR for ReactiveSearch too?
OR
Is React SSR enough?
The primary advantage of SSR in ReactiveSearch is the results are pre-fetched on the server and populated in the ReactiveSearch store which renders them instantly as soon as the page is fetched.
If your usecase does not need the results to be server rendered then just SSR for other react components would be fine.
Note that when you use SSR for reactivesearch the server takes slighly longer to respond since it has to fetch the data from elasticsearch. So, at times SSR might not be the perfect usecase (especially if you're not interested in server rendering the results).
Related
I use only firestore admin to access the database.
I have a function to retrieve the data from firestore. Given a collection name and option parameters (orderBy, startAt, endBefore, limit or limitToLast), it returns the resulting data in an array as well as a string with the url for the next page query and another one for the previous page. Something like this:
export interface FirestorePaginatedResponse {
data: any[],
nextParams?: FirestoreQueryOptions,
prevParams?: FirestoreQueryOptions,
}
export async function paginatedQuery(
collectionPath: string,
basePath: string,
options: FirestoreQueryOptions,
) {
[...]
return {
data,
nextParams,
prevParams,
}
}
So, considering that Static Page Rendering is not an option for Firestore pagination, what would be best for SEO A or B?
A. Do the pagination client side. One landing page with getStaticProps to load the initialData, and then use useSWR hook to retrieve and prefetch the data client side for the next pages. With useSWR probably we would save some reads to firestore due to caching and due to static generation the loading time of the first page would be faster.
B. Do the pagination with server side rendering. The landing page would have a getServerSideProps function to load the data directly given the query parameters before the page is rendered. I think that server rendering might be better for SEO, but maybe the loading of the page would be slower.
In any of those cases the query parameters are read from the url, and the pages are navigated using next/link with href to do the client transition between pages.
EDIT:
I tested 2 pages for pagination with the same content one with getServerSideProps and another one with getStaticProps. The initial loading time of the page is almost the same, so I think I'll be going with the server side rendering as xBurnsed said, for SEO it's better ssr than csr.
As far as I am concerned, the best approach for pagination when it comes to Firestore is to start at the first page, and then cycle through the results using startAfter() with the info of the doc where the last page ended. You can find more information in the following documentation.
Since pagination is meant to prevent loading all documents, I would choose to fetch the documents for each page on demand using the above described method.
Server-side rendering is considered a better option for SEO than client-side rendering. This is because server-side rendering can speed up page load times, which not only improves the user experience, but can help your site rank better in Google search results.
Server-side rendering is also better for SEO because it removes the burden of rendering JavaScript off of search engine bots, which makes it faster for them. Also, not all search engine bots are able to run JavaScript, as stated here.
I am building a website using Express and React. I go with Server-side rendering
Now I am looking for a solution to hydrate my final HTML.
The issue is at the build time, the page is still not available. A page only started with a main component and Express middlewares can add/remove sub-components to that main component. It means we only know what is the final structure of the page at the end of the request
Is there any way I can hydrate that page and make React available in the client browser?
Thank you so much
I am working on one react application.
My requirements are :-
1) First two pages should be rendered always from server side.
2) Rest pages should be client side rendered.
For example :-
http://foo.com and http://foo.com/about I want to rendered always from server side.
http://foo.com/FAQ, http://foo.com/contact I want to render from client side.
what is the right way to achieve this?
You should use ReactDOMServer and specificly renderToString() method.
ReactDOMServer.renderToString(element)
Render a React element 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.
I am building an isomorphic app with React that must support users without JS.
I am new in this technology and I have a basic doubt:
The server can store the components states to emulate what React does in the client-side?
I imagine this flow when the user dont have JS:
The user click a button and send a request to the server.
The server recovers the state of the app and makes changes in it.
The components listen this changes and are rendered again.
Is it correct?
Assuming that you're using react-router :
The server aims to initialize your state, to provide it the default minimum values necessary to make your application work while getting an url.
For example, if you have an application in which you want to display a user list, let say on /users URL, when you'll send your first request, the server will store the users in the react state.
After that first load, you'll be working on the client side using react-router, and making XHR request.
However, if you refresh your page, the process will start again : first load initializing the state and then client side navigation.
EDIT : Explanations =>
When you want to use react on the server, this means that you use a Nodejs server. The fact is that react-dom provides a method called renderToString that transform a react jsx component into standard HTML.
This aims to load the first call faster
Why ?
When you load a "big" JS application on the client, you have some delay time, the time your browser needs to download your JS bundle.
Server side rendering aims to avoid that behaviour, or at least, to gives the feeling that the app starts faster.
In no case you can only use react, even if you use your server side renders. Why ? . Because your events on buttons, or asynchronous load on client, or keypress are in JS language.
I've created a react redux project, now how do I add some SEO functionalities to project? I do not want to waste much time while refactoring codes.
You need to setup the redux store on the server and pass its initial state down to the client, so that the server-render and initial client render don't differ
Not all life cycle functions are called on the serverside, mainly componentDidMount is not called. This indeed helps if you want to do some AJAX data fetching (which you only want to do on the client).
If you are using react-router you need to setup the serverside route matching
Here are some more details: React can be used on server side rendering. What does that mean?