BigPipe compatibility

Created on 17 April 2025, 6 months ago

Problem/Motivation

BigPipe seems to partly work but lazy placeholders don't seem to get rendered client-side. A likely scenario is that they are rendered server-side but at the time of writing, the BigPipe JavaScript only kicks in on a full page load, meaning that it doesn't have a behaviour or event handler.

A good example of where this fails is the shortcuts and user account items in the experimental core Navigation module - these end up empty.

Steps to reproduce

Enable RefreshLess and BigPipe, navigate around while logged in with core Navigation installed.

Proposed resolution

Short term, add a note to the project page that we're not compatible with BigPipe and add a hook_requirements check to prevent installing if the BigPipe module is installed.

Longer term, look into how to support it, probably by a combination of contributing to core and/or implementing some kind of adapter in our JavaScript.

Remaining tasks

TBD.

User interface changes

TBD.

API changes

TBD.

Data model changes

None.

🐛 Bug report
Status

Active

Version

2.0

Component

Code

Created by

🇨🇦Canada ambient.impact Toronto

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

Comments & Activities

  • Issue created by @ambient.impact
  • 🇨🇦Canada ambient.impact Toronto

    Reworked and expanded proposed solutions.

  • 🇨🇦Canada ambient.impact Toronto

    ambient.impact changed the visibility of the branch 3519784-bigpipe-compatibility-routing to hidden.

  • 🇨🇦Canada ambient.impact Toronto

    I think I have it working by decorating BigPipeStrategy in the issue branch. Will let this sit for a bit so I can test it more thoroughly another day.

  • 🇨🇦Canada ambient.impact Toronto

    Sat down and had another look at this. Turns out the initial load was still breaking the BigPipe JavaScript because doesn't handle being in the <head> and with the defer attribute well, most likely because it needs to be render blocking and kick in as early as possible.

    With that figured out, I tried to exclude it from the <head> + defer, but that broke because it needs Drupal.ajax, which was still being output to the <head> with the defer attribute. At that point, I didn't want to mess with the dependency tree because the library handling is already kind of janky and gives me a headache.

    So my next thought was to make a more fundamental change: since our <head> + defer is primarily for RefreshLess requests, why not just let JS be output to the footer without the defer attribute alterations on non-RefreshLess loads, i.e. the initial load. Shockingly, this completely fixed it and BigPipe's JS works as intended on the initial load, and doesn't interfere on subsequent RefreshLess loads. Because nothing in my life ever seems to be easy, my excitement was short lived, as it only works correctly with aggregation off: my clever solution seems to break assets and doesn't load most on an initial load if aggregation is enabled.

    Also note that this causes JavascriptAlterTest to fail, but that can probably be fixed by mocking up the current request in setUp() with the RefreshLess header so that our request wrapper indicates this is a RefreshLess request and alterations are performed.

    I've created a second branch in the issue fork for these changes in case they're not usable at all: 3519784-bigpipe-compatibility-assets. I'll get back to this at some point or someone else can finish this.

    • ambient.impact committed 9e447a2d on cache-and-lazy-preloader
      Issue #3519784: Prevent installing if BigPipe is installed.
      
      This is...
  • 🇨🇦Canada ambient.impact Toronto

    Dear Drupal.org please refresh the cache for this kthx.

Production build 0.71.5 2024