To React, or not to React?
A react framework can make website (application) pages feel like there’s magic burbling up beneath them as dashboard details are kept in concert with a community of lively users, kind of like the experience you expect from Facebook and Twitter.
If you use one reactive element on a handful of pages, then there are ways to confine your reactive code to where and when it is needed. Write server-side, (or even client-side), conditional code to load it. If all you want to do is power popup modals, interactive menus, and tabbed content etc., then the cost vs. benefit consideration of reactive libraries won’t favor them against other approaches.
Rendering strategies for SEO
Application programming in this context typically involves more than the frontend library alone. A convention over configuration file layout design with utility scripts can constitute what is referred to as a framework for React or Vue. Next and Nuxt are NodeJS-based React and Vue frameworks respectively.
Frameworks simplify scaffolding project files and services according to conventional specifications and best practices. Russ provided us with links to GitHub projects demonstrating how to integrate React and Vue with several other popular backend programming languages. Check them out if you want a different runtime process on the backend than NodeJS.
SEO code snippets with NodeJS
When you reach enterprise or startup level requirements, a service level agreement with a framework may not be possible. Russ walks us through getting started with SEO code snippets based on NodeJS (with Express) alone.
Three key files in both sample React and Vue projects contain the necessary code for our analysis:
- The app.js file governs a “blog” app shell.
- The server.js file pulls in the Express library, configures it for request handling including render methods for SSR.
- The index.js file, serves as the entry point for the NodeJS runtime process.
The App.js example for React demonstrates routing SEO friendly paths to URLs that don’t rely on fragments for SPA-style virtual page views. In server.js a ‘context’ data object implies resource details for calling
ReactDOMServer.renderToString() to render our app shell with context based on URL and potentially other criteria.
The server.js file has the data context object for more refinements. Russ demonstrates replacing title and other meta data to complete the SEO for a constructed app shell before finally sending it on its way to the browser.
Lastly, index.js serves as the starting point for the NodeJS process and
ReactDOM.hydrate() is used to flesh out our app with less important auxiliary content after the shell loads.
A ‘build’ directory contains index.html as a target file for SSR template construction. Two other files, the components Home and Posts, are stored using a .js extension, which is implied by convention and therefore does not need to be explicitly spelled out in the import statements. We’re going to expediently skip analysis of component files, except to say that it’s typical to find component files re-organized into a components subdirectory.
In Russ’s examples, all files, including component files, are located in the project base directory. This is what the directory tree for the React files looks like:
│ └── index.html
Russ makes use of react-router-dom libraries (which you may need to install via NPM): Router and StaticRouter, Switch, and NavLink. These libraries provide readymade helpers for convenience with common tasks, such as using the NavLink ‘to’ helper to generate HTML links to a url path or resource, which is somewhat analogous to Rail’s ‘link_to’ helper.
Through Switch and Router in App.js Russ demonstrates the syntax for matching url paths. Notice the ‘exact’ keyword for the index path statement. It’s required to match only exactly ‘/’ or it would otherwise match every path of the application! Using the ‘exact’ keyword changes the default criteria from greedy match which matches ‘/posts’ and also ‘/posts/hello-world’ etc.
In server.js Russ makes use of a common external framework called Express to set up our application with the required port listener and response methods needed to serve our app on the network. If you are working locally, you’ll want to establish a local environment variable PORT to match an open port that you plan to work with via localhost requests. In production, this will usually need to get set to port 80.
Russ points us to the Vue SSR documentation and his code snippets operate using essentially the same file structure and layout for implementation of the Vue version of our blog app. Find the code for both React and Vue available below in the following Gist.