Once #1014086: Stampedes and cold cache performance issues with css/js aggregation 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).
Comments
Comment #2
catchComment #3
nod_Comment #4
catchComment #5
andypostI recall more related issues about ajaxPageState
Probably it's time to consider how core manage it
It reminds me won't-fixed native modules #1542344: Use AMD for JS architecture
Comment #6
nod_I'm looking at supporting native modules in 10+ since browser support is good, mentioned it in #3302755-14: On-the-fly JavaScript minification. Using AMD for js module is won't fix, not the whole supporting modules concept. In any case we will still have libraries in some way, that's an intermediary step we can't really remove in Drupal. The question is what will it take to have the libraries are automatically generated based on the js code (for example with something like this #3050386-26: Allow loading CSS and JavaScript directly from templates) and stop having so much manual declaring to do.
But that's a bit off topic for this issue. Not sure what you mean by managing ajaxPageState?
Comment #7
wim leersFascinating! 🤓
Comment #8
catchAfter #3303067: Compress aggregate URL query strings the list of libraries (in both 'include' and 'exclude') in the query strings is compressed.
However, for #956186: Allow AJAX to use GET requests, we probably want
ajax_page_stateitself 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.
Comment #9
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.