Allow to merge AjaxCommands inside of AjaxResponse

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

There is an addCommand method that does much more than a simple array_merge so there is bound to be issues doing it this way.

MR should be against 10.1.x since that is the current dev version

Naming of the new function is not ideal. It's not about setting commands, I'd be more of a mergeCommands method
At the moment commands can be added the addCommand method, so what the issue raised could be worked around @Mschudders would that be enough?

Rebased to be up-to-date.

Can the MR be updated for 11.x as that's the current development branch.

Also could use a simple test assertion to show it's working.

Still needs test.

The module Layout Builder Extras - live update requires this patch.

Added patch of MR for use in composer.
Applies to both 11.x and 10.3.x

I have added test coverage for the mergeCommands method, and the pipeline issues have also been resolved.
I am now moving this for review. Please take a look.

Have not reviewed but this one has multiple branches and multiple MRs up those should be cleaned up or summary updated.

I have cleaned up the branch. MR 4902 now contains all required updates and is ready for review. Additionally, I have updated the issue summary for clarity.
Moving this MR to Review. Kindly review the changes.

This appears to be an API change but that section is missing from the summary. Recommend not removing sections from an issue template even if you aren't sure it applies.

API change will need a change record

Thank you for your review and feedback; I'll incorporate this. I've updated the issue summary and added a draft mode change request for review.
Please take a look and let me know if there’s anything further needed to update.

Tweaked the CR with an example, but rest seems good.

Shouldn't that be called mergeResponse?

I think the method name mergeCommands was chosen to align with the existing structure of the AjaxResponse class, which focuses on handling and manipulating commands, as seen in methods like addCommand and getCommands. However, if there’s a preference to rename it to mergeResponse for better clarity or to better reflect its purpose, I’m open to making that change. Let me know your thoughts!

This is requiring that the command is rendered before it's merged in. I would expect you could pass actual commands here, not already rendered commands, to match addCommand(). And even if there's a reason that can't be done, the documentation doesn't specify what the actual contents of the argument is.

Also it will result in the attachments logic in AddCommand not running, and the new test coverage does not cover that - it's not clear at all what will happen to the attachments.

@nod_'s mergeResponse() suggestion might be able to handle it, if you passed in the full AjaxResponse object, and this method then extracted both the rendered commands and the attached from it.

Either that, or I think we need to look at refactoring things a bit more, so that commands are not immediately rendered when added, and so that ::getCommands() or a new getAjaxCommands() method can return command objects.

Looks good to me, marking as RTBC, thanks!

The issue summary and change record could use an update here since they no longer reflect the approach in the MR.

Updated, including tests a bit as well to illustrate direct usage of

return $response->mergeWith($other);

Left a few small comments on the MR

If you are another contributor eager to jump in, please allow the previous poster at least 48 hours to respond to feedback first, so they have the opportunity to finish what they started!

I'll update the code to fix the comments

Tests are failing :(

Hi, I have re-run the previously failed test and it has now passed. It appears to have been a random failure :)

Ok then we can set this to needs review. Thanks.

All threads resolved. Just a small note to @smustgrave: @param doc comments are not needed if parameters are well described by their names and type hints and that was the case here.
Setting to RTBC.

Do you have a docs or policy page that mentions that by chance?

Just that I remember some time before @var and @param tags were required by our coding standards and it's no longer the case. Probably because of type hints that make them obsolete in a majority of cases.

Coding standards still require @param everywhere, it will change soon when #3376518: Allow omitting @var, @param and @return tags or their descriptions if the variable name and type is enough is adopted although only in specific circumstances.

This looks good to me. Committed/pushed to 11.x, thanks!