##pnx-sprint

#79 is not applying for me on 10.3.1

Ran test-only feature

1) Drupal\Tests\media\Functional\MediaOverviewPageTest::testMediaOverviewAuthorFilter
Behat\Mink\Exception\ElementNotFoundException: Form field with id|name|label|value "name[media_field_data.user_name]" not found.
/builds/issue/drupal-3113989/vendor/behat/mink/src/WebAssert.php:731
/builds/issue/drupal-3113989/core/tests/Drupal/Tests/UiHelperTrait.php:85
/builds/issue/drupal-3113989/core/modules/media/tests/src/Functional/MediaOverviewPageTest.php:219
FAILURES!
Tests: 2, Assertions: 58, Failures: 1.

Manually testing editing the view I'm seeing the new filters.

Believe this is good

I have reroll patch no 126 as per drupal version 10.3.1.

I hate to be the bearer of bad news on such a long sought after solution for this, but the patches above do not work for 10.3 (I can't verify for Drupal 9 and below). This is also not an ideal nor practical solution. The getBlockFromAjaxRequest() method that was added does not return the expected results. The block gets a duplicate config key and also returns null on the first ajax request via elementPreRender(). The preBlockBuild() function does not get called still because the ajax architecture only returns the view (the block is a wrapper around the view and does not get updated).

My solution for the client that needed this was as follows:
1. Add Drupal JS settings for views blocks: $build['#attached']['drupalSettings']['viewsBlock'][$this->view->dom_id] = $block->getConfiguration();
2. Add a new method to the views block display and views block plugin to add the settings to the build: alterBlockBuild(ViewsBlock $block, &$build)
3. Add an event subscriber with a that responds to the ViewAjaxResponse response and checks for the block display handler
4. Add an ajax command that responds on ajax and uses the block settings for updating the view

I really think our proposed solution should be changed to something similar to above. This way is much cleaner and follows the ajax workflow mostly with views. Any module that overrides views block settings could then implement their own subscriber and ajax commands with the new viewsBlock drupal settings in the block build.

I spent over 25 hours on this issue, and the only way I could get block settings to update the view, was via drupalSettings on the views block and an ajax command that fires on the response of ViewsAjaxResponse.