Dynamically determine ajaxPageState based on libraries

Created on 6 May 2022, about 2 years ago
Updated 11 April 2023, about 1 year ago

Problem/Motivation

Once πŸ› Stampedes and cold cache performance issues with css/js aggregation Fixed lands, aggregate generation will also be entirely determined by libraries (instead of stored hashes of calculated assets). This is because the aggregate URLs on a page will themselves contain the list of libraries requested as well as already-loaded libraries on a page.

As a result, we should be able to determine ajaxPageState on demand, only when it's needed - by parsing those URLs in JavaScript instead of always putting a huge array into drupalSettings.

See nod_'s comment in #1014086-238: Stampedes and cold cache performance issues with css/js aggregation β†’ for the original idea.

This may in-turn simplfy some other issues (see related).

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

πŸ“Œ Task
Status

Active

Version

10.0 ✨

Component
Asset libraryΒ  β†’

Last updated about 1 hour ago

No maintainer
Created by

πŸ‡¬πŸ‡§United Kingdom catch

Live updates comments and jobs are added and updated live.
  • JavaScript

    Affects the content, performance, or handling of Javascript.

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.

  • πŸ‡¬πŸ‡§United Kingdom catch

    After πŸ“Œ Compress aggregate URL query strings Fixed the list of libraries (in both 'include' and 'exclude') in the query strings is compressed.

    However, for πŸ“Œ Allow AJAX to use GET requests Fixed , we probably want ajax_page_state itself to be compressed too so it's not too long as a query parameter (currently sent in POST to AJAX requests). I haven't actually implemented this bit yet, but it's probably the next step for that issue - at least a proof of concept to see how tricky it is.

    Since we don't actually use the library information in ajax_page_state in JavaScript, just pass it around, I think the fact it's compressed probably won't matter at all for this issue.

  • πŸ‡¬πŸ‡§United Kingdom catch

    #3348789-21: Compress ajax_page_state β†’ might make this harder, since it compresses all of ajaxPageState not just the libraries, but we should probably just try and see.

    Another thing I didn't think of before, but affects this, is that we only put the libraries in the query string when aggregation is on, but we still need ajaxPageState when aggregation is off, so would have to do something when there's all the individual CSS and JS added to the page too.

Production build 0.69.0 2024