WordPress provides a REST API that has good online documentation that includes information such as type definitions and route information(WordPress, n.d.).
Fetching & Server Side Rendering
As the data is stored on an external storage system, the server hosting the WordPress application, the page can not be directly served with the data if it is rendered on the client. By rendering the page on the client using Reacts default rendering technique the user will have to wait for the data to be fetched, parsed and then rendered.
A small subset of the post information is rendered for this page as the entire post is not required. To reduce the amount of fields returned from the REST API the ?_fields?= query is used, as shown below.
To avoid this issue the data for the blog index page, the page that renders the posts and their excerpts, is rendered on the server. The data fetching is handled by the server meaning that when the client receives the page all of the data fetching has already been done for them.
Each excerpt contained some additional text that needed removed before the text could be displayed. A custom regular expression was created to remove these sections of text.
Rendering A Blog By ID Using Incremental Static Regeneration
By using NextJs dynamic routing and NextJs Incremental Static Regeneration each blog post is rendered at build time, meaning the amount of data fetching by the application is reduced(NextJs and Vercel, n.d.). Each post is cached by the application and is periodically checked for new data. This allows the application to provide fast loading times for the blogs without having to query the server running WordPress every time a user wishes to access the blog. The following code displays how this feature is implemented:
The HTML provided by WordPress is used directly within the DOM, along with the stylesheet used by the WordPress theme. This ensures consistency across both the NextJs application and the blogs viewed directly via WordPress.
This method of using dangerouslySetInnerHTML is not advised unless you have full control of the data source and can therefore trust the data being sent. As all posts are created by me I know there is no malicious code being sent into the content of the blog post, so this method is okay to use. This approach can be acceptable in certain circumstances. For example, one of the example projects provided by the NextJs team uses this approach to render HTML generated from Markdown files that the developer controls(Neutkens, Uesugi and Alvarez D, n.d.).
The following provides some example screenshots of a post accessed using the NextJs project and the same post accessed using WordPress.
NextJs
WordPress
This post has outlined how posts are fetched and rendered within the NextJs application developed for this project. By using NextJs Incremental Static Regeneration the amount of times the WordPress server is queried is reduced, while improving the users experience by reducing load times and JavaScript bundle size. Consistency in styling is achieved by reusing the same stylesheet used by WordPress for the blog posts meaning the layout of posts previewed using Gutenberg can be expected to look the same across both applications.
References
Neutkens, T., Uesugi, S. and Alvarez D, L. (n.d.). next.js/examples/blog-starter/components/post-body.js. [online] GitHub. Available at: https://github.com/vercel/next.js/blob/canary/examples/blog-starter/components/post-body.js.
NextJs and Vercel (n.d.). Basic Features: Data Fetching | Next.js. [online] nextjs.org. Available at: https://nextjs.org/docs/basic-features/data-fetching#incremental-static-regeneration.
WordPress (n.d.). Posts | REST API Handbook. [online] WordPress Developer Resources. Available at: https://developer.wordpress.org/rest-api/reference/posts/.
Comments
Post a Comment