A Foot In Each Realm: Zero-Bundle-Size React Server Components
2020 ended with a very interesting update from the React team at Facebook. They announced that they are currently experimenting with a revolutionary new concept in React: Zero-Size-Bundle React Server Components (see the React team’s announcement here). Behind the verbosity of this name is a fundamental shift in how React works. The basic idea is that some components may be rendered on the server. The motivation behind this is the same motivation behind many of React’s releases: performance. Zero-Size-Bundle React Server Components are not yet in production and are still very much in a research and development phase. Therefore, it will probably be some time yet before React engineers can make use of them. However, the announcement provides a fascinating insight into what is coming down the line, and how front-end engineering is likely to evolve in the near future.
Server Components
In what is currently being envisaged by Facebook’s React team, a server component file would have a .server.js extension. This would differ from a regular client component (or ‘silent’ component) file, which would have a .client.js extension.
Such a component must be one that does not require interaction with a state management system, such as Redux, or include event listeners. Instead, it must only render data for display purposes.
The two main pillars of Zero-Size-Bundle React Server Components are potentially vastly reduced bundled JavaScript file sizes and direct access to databases from within React components (thus somewhat reducing a need for front-end state management in certain cases).
Reduced Bundled File Sizes
By rendering a React component on the server, a serialised format of the rendered component is sent directly to the browser, without a need for the component to be created and executed on the front-end. The result is that the bundled JavaScript file that is created at build-time may be significantly smaller than it would otherwise be. This is especially so when the component requires third party modules to complete an operation, such as date formatting, etc. The module is imported and used on the server and the browser is oblivious to it. As of now, the module must be imported on the browser side by inclusion in the bundled JavaScript file. Some of these modules can be very substantial in size, thus contributing significantly to load-time and performance. By removing the need to import some third party modules on the front-end, the bundled file size can be made much smaller.
Direct Access To Database
With such a component being rendered on the server, it is possible to make direct queries to a database in order to access data quickly and without a need for separate server calls (each of which significantly adds to load-time and impacts upon overall user experience). Also, since state management systems, such as Redux, are used for the purpose of storing data that is returned by server requests, state management may not be required in cases where data is directly accessed from a database by the component. The consequent reduction in client-side JavaScript would be greatly impactful on the size of that client-side bundle.
Organising Server Components
As with any React component, server components would be re-rendered when the props to that component change. Therefore, a new call to the server would be made on each such occasion. As with code-splitting in React, a route-based organisation of server components may be an efficient way to manage these (if appropriate), as server requests would take place on route changes.
Structuring as Shared Components
In an application, it would make sense to have both silent components and server components. In addition to both of these component types are shared components (the files for which have an extension of .js). Such a component is by itself agnostic of whether it belongs on the server or on the client. Instead, it becomes a server component if and when it is imported directly into a server component. And it becomes a silent component if and when it is imported into a silent component. Thus, a shared component enables the best of both worlds: both server-side rendering and client-side rendering, and it also shares code between both realms.
Again, Zero-Bundle-Size React Server Components are not yet ready for release to production and it will probably be some time before they can be used by the community. However, if and when they are made available in a future release, they promise to be a game-changer for React engineers and consequently for products that utilise React. The degree of impact on performance will be matched by an impact on mindset and approach when building software.
