We are introducing: 1. Server Side Rendering (aka SSR) and bulk query execution support in Reactivesearch. This will significantly improve how our components behave and talk to the Elasticsearch server. Let’s talk about them briefly here:

1. Server Side Rendering

Normally when building applications with React, your browser will download the HTML page and the JavaScript bundle generated for your app to render the react app components on the client side. This process is called Client Side Rendering(CSR).

Client Side Rendering with Reactivesearch components. Credits: Bela Bordeaux

This is great and works well but it comes with a downside — it’s hard to improve the first meaningful paint of the content since a lot of computation needs to happen to render the react components on the client-side. This computation is usually fast, but it can start having a noticeable impact as the number of components increase in your application.

With Server Side Rendering (SSR), the desired HTML is computed and rendered on the server before being sent to the client. The following illustration illustrates the difference.

Server Side Rendering with Reactivesearch. Credits: Bela Bordeaux

SSR with React enables us to generate the initial content on the server, so the browser can download the pre-determined HTML content of your react app and significantly improve the first meaningful paint of your application. It lets you consequently handle the updates in the browser and make the entire experience feel seamless. This allows:

Faster loading of pages — You will not see any flickering or loading animations while rendering your app on an initial load. The response from the server is the HTML of your react app that is ready to be rendered. Better SEO — Since the response from your SSR application is HTML, the content is more easily accessible to search engine crawlers than that of a dynamically rendered CSR application.

With v2.6.0 , SSR support (which had been pending for a while) has fully landed in reactivesearch. 🎉

On an average, first meaningful paint for apps solely built with reactivesearch is ~50% faster (on a slow 3G network).

SSR makes a lot of sense for use-cases where we’d typically want to get the results rendered as fast as possible, and not worrying about their interactivity during the initial few seconds of the page load. This improves the user experience for products like e-commerce where you can utilise SSR to render results quickly and subsequently making the app interactive by lazily loading the javascript bundle.

👉 Get started with SSR with Reactivesearch here.

👉 Check out these example SSR apps built with reactivesearch.

👉 Demo Reactivesearch SSR App deployed with now.sh

2. Combined execution of async query requests

We have gone a step further and added support for _msearch based query execution in the core of ReactiveSearch. This enables us to evaluate and execute multiple queries together whenever possible (saving on a lot of API fetch requests).

Network Requests — Before and After Query Combination

This enhancement also powers the underlying implementation for SSR wherein we make only one API request to fetch the results of all reactive-components present in an app. Together, these changes will significantly improve the performance of the apps built with Reactivesearch v2.6 and above.

Other Changes and Bug Fixes

Typescript support 🎉 — We now fully support Typescript definitions for reactivesearch components. So if you are using Typescript with reactivesearch, you should feel right at home. Improved query generation with complex react props 🤖 — We have also updated the core logic to enhance the query generation for complex ( react prop) use-cases. With this, you can now easily manage apps with complex OR, AND, NOT based relationship between the reactive-components. Read more about its usage here. Better error handling ⚠️ — We have added support for onError methods on all result components which allows better handling of network or query related errors.

Useful links