HTML responses, Ajax responses, and BigPipe already have an attachments array to build an AttachedAssets collection. But in absence of an appropriate factory, HTML processor and BigPipe wrap their array in a temporary render array, while the Ajax processor initializes the collection from ground up.
A factory for attachments arrays would give these callers a clear path to initialize libraries and JavaScript settings.
See how HtmlResponseAttachmentsProcessor, AjaxResponseAttachmentsProcessor, and BigPipe create their asset collections.
We should add AttachedAssets::createFromAttachments() and use it in all three callers, with more being proposed in #3532803: Ajax OpenDialogCommand doesn't load necessary libraries, plus AssetControllerTest plus Contrib.
In createFromRenderArray() we keep the existing LogicException when #attached is missing or NULL. Otherwise, we pass $render_array['#attached'] directly to our new createFromAttachments() and return the resulting collection.
None.
None.
Adds AttachedAssets::createFromAttachments(array $attachments). Otherwise unchanged.
None.
Module developers may now pass an array of attachments directly to AttachedAssets::createFromAttachments() to initialize an asset collection with libraries and JavaScript settings.
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
panchoComment #4
nitinkumar_7 commentedOne thing seems to be missing from this change. The issue mentions updating all three callers, including `
AjaxResponseAttachmentsProcessor`, which currently initializes `AttachedAssets` manually.Could we also update the AJAX response processor to use the new
`createFromAttachments()`factory? That would make the implementation consistent with the proposed resolution and cover all three use cases mentioned in the issue.Comment #5
panchoYou are right, I missed that one, thanks.
Also drafted a change record.