Closed DFurnes closed 9 years ago
Two potential ways of handling this –
I'm in favor of the dedicated Node process for now. There's nothing inherently inelegant about having multiple, purpose-dedicated processes on the back end. And I'd much rather we reuse existing elements in our tech stack (NodeJS) than add in experimental components (PHP v8 support).
In the future, I'm sure something will standardize and stabilize for Laravel-React support, and we can reconsider.
Agreed! Morgan & I were looking at the PHP v8 extension the other day and it looked pretty crazy. I just pushed up a PR with a proof-of-concept of Option 2 for review/discussion.
Merged in an initial stab at this in #348, and deployed to www.catsgonegood.com. Seems to be working pretty nicely when I tried SSH'ing in and manually running the Node renderer process.
Just leaving a note here –– manually started a forever process on Cats Gone Good to run the boostrap/react_server.js
pre-rendering service for Specialists Guild testing. We'll need to update the Capistrano script to start or restart that process when we deploy in the future.
Closing this, since only remaining task is to update deploy so we don't have to manually restart the Node process.
This is more of a nice-to-have than a necessity. Right now, we're rendering server-side views using Blade, and then wiping the DOM and re-rendering a nice client-side interface in React on page load. Ideally, we can use React's
renderComponentToString
functionality to pre-render the interface on the server. Then all React has to do is attach event listeners on page load.