use Spatie\Ssr\Renderer;
use Spatie\Ssr\Engines\V8;
$engine = new V8();
$renderer = new Renderer($engine);
echo $renderer
->entry(__DIR__.'/../../public/js/app-server.js')
->render();
// <div>My server rendered app!</div>- Works with any JavaScript framework that allows for server side rendering
- Runs with or without the V8Js PHP extension
- Requires minimal configuration
If you're building a Laravel app, check out the laravel-server-side-rendering package instead.
This readme assumes you already have some know-how about building server rendered JavaScript apps.
We invest a lot of resources into creating best in class open source packages. You can support us by buying one of our paid products.
We highly appreciate you sending us a postcard from your hometown, mentioning which of our package(s) you are using. You'll find our address on our contact page. We publish all received postcards on our virtual postcard wall.
Server side rendering (SSR) can be hard, and non-trivial to enable in your JavaScript application. Before using this library, make sure you know what you're getting in to. Alex Grigoryan has a pretty concise article on the benefits and caveats of SSR. Anthony Gore also has a great article on server side rendering a Vue application in Laravel, which inspired this library.
In case you're in need of a refresher...
- SSR reduces the time until the first meaningful paint, providing a better experience for your users
- SSR is recommended if you need to tailor your app for crawlers that can't execute JavaScript (SEO)
- SSR adds a meaningful amount of complexity to your application
- SSR can increase response times and the overall load on your server
When you've got an answer to the "Do I need SSR?" question, ask yourself if you need SSR in a PHP application. Benefits of rendering your app in a PHP runtime are:
- Access to your application's session & state, which you normally don't if your SPA is consuming a stateless api
- Reduced infrastructure complexity because you don't need to maintain a node server
If you're building a SPA that connects to an external API, and the PHP runtime doesn't provide any extra value, you're probably better off using a battle tested solution like Next.js or Nuxt.js.
As a final disclaimer, judging by the amount—well, lack—of people blogging about rendering JavaScript applications in PHP, this whole setup is uncharted territory. There may be more unknown caveats lurking around the corner.
If you're still sure you want to keep going, please continue!
You can install the package via composer:
composer require spatie/server-side-renderingThis guide assumes you already know how to build a server-rendered application. If you're looking for reading material on the subject, Vue.js has a very comprehensive guide on SSR. It's Vue-specific, but the concepts also translate to other frameworks like React.
An engine executes a JS script on the server. This library ships with two engines: a V8 engine which wraps some V8Js calls, so you'll need to install a PHP extension for this one, and a Node engine which builds a node script at runtime and executes it in a new process. An engine can run a script, or an array of multiple scripts.
The V8 engine is a lightweight wrapper around the V8Js class. You'll need to install the v8js extension to use this engine.
The Node engine writes a temporary file with the necessary scripts to render your app, and executes it in a node.js process. You'll need to have node.js installed to use this engine.
You can chain any amount of options before rendering the app to control how everything's going to be displayed.
echo $renderer
->disabled($disabled)
->context('user', $user)
->entry(__DIR__.'/../../public/js/app-server.js')
->render();Enables or disables server side rendering. When disabled, the client script and the fallback html will be rendered instead.
When debug is enabled, JavaScript errors will cause a php exception to throw. Without debug mode, the client script and the fallback html will be rendered instead so the app can be rendered from a clean slate.
The path to your server script. The contents of this script will be run in the engine.
Context is passed to the server script in the context variable. This is useful for hydrating your application's state. Context can contain anything that json-serializable.
echo $renderer
->entry(__DIR__.'/../../public/js/app-server.js')
->context('user', ['name' => 'Sebastian'])
->render();// app-server.js
store.user = context.user // { name: 'Sebastian' }
// Render the app...Context can be passed as key & value parameters, or as an array.
$renderer->context('user', ['name' => 'Sebastian']);$renderer->context(['user' => ['name' => 'Sebastian']]);Env variables are placed in process.env when the server script is executed. Env variables must be primitive values like numbers, strings or booleans.
$renderer->env('NODE_ENV', 'production');$renderer->env(['NODE_ENV' => 'production']);Sets the fallback html for when server side rendering fails or is disabled. You can use this to render a container for the client script to render the fresh app in.
$renderer->fallback('<div id="app"></div>');Add a callback to transform the entry when it gets resolved. It's useful to do this when creating the renderer so you don't have to deal with complex paths in your views.
echo $renderer
->resolveEntryWith(function (string $entry): string {
return __DIR__."/../../public/js/{$entry}-server.js";
})
->entry('app')
->render();composer testPlease see CHANGELOG for more information what has changed recently.
Please see CONTRIBUTING for details.
If you've found a bug regarding security please mail security@spatie.be instead of using the issue tracker.
You're free to use this package, but if it makes it to your production environment we highly appreciate you sending us a postcard from your hometown, mentioning which of our package(s) you are using.
Our address is: Spatie, Kruikstraat 22, 2018 Antwerp, Belgium.
We publish all received postcards on our company website.
The MIT License (MIT). Please see License File for more information.
