Contrib.social

Render a JSON-LD respresentation of the page in the <head>

Open on Drupal.org →
Created on 6 March 2019, over 6 years ago
Updated 28 May 2025, about 1 month ago

Problem/Motivation

There isn't a straightforward way to render content on the server, and also have that content loaded by a client-side framework for rending a UI.

The choices are to either:
1) Render the page with Drupal.
2) Render the page with Node.js and forget about Drupal
3) Don't use server-side rendering and make a request to Drupal for the content.

Proposed resolution

Since Google prefers JSON-LD in the html head and since schema.org provides types for nearly anything needed (header, footer, sidebar, navigation, etc.), then a templating engine should be created to take the represenation of the page and generate a blank page with the representation in JSON-LD format in the head.

This representation would allow machines to read the contents of the page on server-load, and also allow a JavaScript framework to read the page without making another request to the server.

The RDF module should be used to create a mapping from an entity/field to a schema.org type and property, but if that mapping does not exist, it should map to a dynamic schema that reflects the configuration of the site (i.e. the entity type, bundle, field, etc.). This way the JavaScript framework can read the contents of the page without it having to match perfectly the schema.org metadata.

Also, an API should exist (query parameter?) to request a represenation of the page in JSON-LD format (without the HTML wrapping it). This way if a user navigates within the JavaScript UI, the entire page can be updated based on the response to the URL they are trying to go to.

Remaining tasks

  1. Create a JSON-LD template engine
  2. Create a "base" theme that uses the new engine

User interface changes

None

API changes

Allows themes to be completely JavaScript driven, but also preserve "server-side rendering"

Data model changes

None.

Release notes snippet

N/A

✨ Feature request
Status

Postponed: needs info

Version

11.0 🔥

Component

jsonapi.module

Created by

🇺🇸United States davidwbarratt

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment about 1 month ago →
    🇳🇿New Zealand quietone

    The Ideas project is being deprecated. This issue is moved to the Drupal project. Check that the selected component is correct. Also, add the relevant tags, especially any 'needs manager review' tags.

    Changing to the standard issue template → would also help other contributors.

    Is feature still desired in core?

  • Comment about 1 month ago →
    🇺🇸United States davidwbarratt

    I think the problem is correct, but the proposed solution is not. Since I wrote, things like Core Web Vitals make #3 as well as the proposed solution, not viable options since that will make the LCP metric significantly worse. Waiting for all of the JS to load before you get anything on the page, even if there isn't a server request, basically renders the browser's streaming rendering of HTML useless.

    I guess this isn't really a core problem and can be solved in contrib. I'm wondering if we could provide a mechanism to compile JS components to executable binaries. That would basically give developers the ability to use JS frameworks at template level without having to sacrifice server-side rendering.

    I'll probably write a little PoC to see if this is even possible, but that seems like a better solution than having developers rebuild the entire front-end with Next.js (or whatever).

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024