BlogArticlesList currently obtains recent Podman blog posts through the useBlogPosts React hook. The hook performs a client-side request to the WordPress REST API from useEffect() after the page has loaded.
This means the homepage and Features page depend on an external API request during runtime to populate content that is otherwise static and can be determined during the Docusaurus build.
Currently the rendering path is:
Page load
|
React hydration
|
useEffect()
|
WordPress API request
|
setState()
|
BlogArticlesList renders
For a statically generated site, this introduces an unnecessary runtime dependency for content that could be resolved during the build.
Why this matters
If the WordPress API is unavailable, slow, rate-limited, or unreachable from a user's network, the latest-post section cannot be populated even though the rest of the site is available.
It also means the blog cards are not part of the initial generated HTML and require JavaScript execution and a subsequent network request before becoming available.
Suggest potential solution
Move the WordPress API request into the Docusaurus build process and expose the resulting blog metadata to the page at build time.
for eg.
WordPress REST API
|
Docusaurus build
|
generated blog metadata
|
BlogArticlesList
The generated data should contain only the fields currently required by ArticleCard, such as:
post ID
title
author
author URL
date
featured image
post URL
excerpt
The React component can then become a presentational component that receives already-available data rather than managing its own network request and loading state.
Expected outcome
The latest blog posts should be available as part of the generated site without requiring a client-side WordPress API request after page load.
Have you considered any alternatives?
There are 2 approaches that we can discuss:
API response validation + typed boundary
Right now useBlogPosts.ts essentially does:
const jsonData = await rawData.json();
setData(jsonData);
There is no validation that the WordPress response actually conforms to the BlogPost interface.
The TypeScript interface gives the compiler an expected shape, but it does not validate runtime JSON.
That creates a genuine boundary problem:
External API
|
untrusted JSON
|
TypeScript assertion/assumption
|
React components
A stronger architecture would be:
External API
|
validate/normalize
|
BlogPost[]
|
React
We can use a lightweight schema validator or a custom normalization function.
Centralize/cachе WordPress API data
BlogArticlesList is used in multiple places. The homepage renders it with:
<BlogArticlesList limit={4} ... />
while the Features page renders it separately with:
<BlogArticlesList
limit={2}
...
/>
Because the hook performs its own fetch() for every mounted instance, the architecture can potentially produce multiple independent requests to the same external service.
We can instead introduce a shared data layer:
WordPress API -> cache/data layer -> Homepage, Features
rather than:
Homepage → WordPress API
Features → WordPress API
This is especially interesting because the data is external and relatively slow-changing.
Since This issue is related to architecture, I would like to get views of maintainers on it before moving forward
BlogArticlesList currently obtains recent Podman blog posts through the useBlogPosts React hook. The hook performs a client-side request to the WordPress REST API from useEffect() after the page has loaded.
This means the homepage and Features page depend on an external API request during runtime to populate content that is otherwise static and can be determined during the Docusaurus build.
Currently the rendering path is:
Page load
|
React hydration
|
useEffect()
|
WordPress API request
|
setState()
|
BlogArticlesList renders
For a statically generated site, this introduces an unnecessary runtime dependency for content that could be resolved during the build.
Why this matters
If the WordPress API is unavailable, slow, rate-limited, or unreachable from a user's network, the latest-post section cannot be populated even though the rest of the site is available.
It also means the blog cards are not part of the initial generated HTML and require JavaScript execution and a subsequent network request before becoming available.
Suggest potential solution
Move the WordPress API request into the Docusaurus build process and expose the resulting blog metadata to the page at build time.
for eg.
WordPress REST API
|
Docusaurus build
|
generated blog metadata
|
BlogArticlesList
The generated data should contain only the fields currently required by ArticleCard, such as:
post ID
title
author
author URL
date
featured image
post URL
excerpt
The React component can then become a presentational component that receives already-available data rather than managing its own network request and loading state.
Expected outcome
The latest blog posts should be available as part of the generated site without requiring a client-side WordPress API request after page load.
Have you considered any alternatives?
There are 2 approaches that we can discuss:
API response validation + typed boundary
Right now useBlogPosts.ts essentially does:
const jsonData = await rawData.json();
setData(jsonData);
There is no validation that the WordPress response actually conforms to the BlogPost interface.
The TypeScript interface gives the compiler an expected shape, but it does not validate runtime JSON.
That creates a genuine boundary problem:
External API
|
untrusted JSON
|
TypeScript assertion/assumption
|
React components
A stronger architecture would be:
External API
|
validate/normalize
|
BlogPost[]
|
React
We can use a lightweight schema validator or a custom normalization function.
Centralize/cachе WordPress API data
BlogArticlesList is used in multiple places. The homepage renders it with:
<BlogArticlesList limit={4} ... />
while the Features page renders it separately with:
<BlogArticlesList
limit={2}
...
/>
Because the hook performs its own fetch() for every mounted instance, the architecture can potentially produce multiple independent requests to the same external service.
We can instead introduce a shared data layer:
WordPress API -> cache/data layer -> Homepage, Features
rather than:
Homepage → WordPress API
Features → WordPress API
This is especially interesting because the data is external and relatively slow-changing.
Since This issue is related to architecture, I would like to get views of maintainers on it before moving forward