Hide block/view if No results behavior

@coaston how do you come to this conclusion?

Comparing the commit from the linked issue
https://git.drupalcode.org/project/entity_extra_field/-/commit/94a2ab3dc...
to the latest branch:
https://git.drupalcode.org/project/entity_extra_field/-/blob/2.1.x/src/P...

it's present!

it's present!

Coaston means to say that the original commit is incomplete, not that the commit is missing.

The MR created by jnettik implemented the fix in a different way from the patch file submitted by artyom. Namely:

• The MR implementation simply calls Element::isEmpty()
• The patch file implementation additionally executes the view to check if the rendered output is empty

This is significant in the special case of views because as explained 🐛 Empty content view Fixed :

ViewExecutable will build a render array regardless of whether it has anything to display, because the view is not executed until render time, and hence just checking the render array it not reliable, which is all Element::isEmpty() does.

The Drupal Core views block display plugin (\Drupal\views\Plugin\views\display\Block::execute()) suggests that the correct way to check is to actually execute the view with arguments, then check $view->getDisplay()->outputIsEmpty(), which is how the plugin implements its "Hide block if the view output is empty" option.

I can confirm that this patch solved the issue of a View block with empty output. I will take a look at the approach and see if it can be improved.

Upon further reflection on this issue, there are two potential solutions for using Entity Extra Fields to render Views. A developer can implement this using either the Views or the Block plugin within the Entity Extra Field module. I currently do not recommend supporting views being rendered in the block plugin when we have a Views plugin available. I've added some additional code to the Views Plugin within the Entity Extra Field module to address this issue. Please let me know if this addresses the issue you're personally experiencing.

Thank you, your patch works as expected. No issue found. I think it is ready to be merged.

@coaston thanks for the RTBC. Could you please create a MR from the patch? Thanks!

Working on it!!

Converted the patch to MR,
please review!!

Thanks for the MR. Back to NR, would be nice if someone here could test it (or even better add a test)!

Code-wise this LGTM, still there might be an impact on performance, as each view is now executed twice? Do we have a way to improve that or are there better ways?
Otherwise I'd be fine to merge this after review. Thank you! :)