Allow plugin derivative classes to use services from the container

+++ b/core/modules/views/lib/Drupal/views/Plugin/Derivative/ViewsBlock.phpundefined
@@ -24,6 +26,43 @@ class ViewsBlock implements DerivativeInterface {
   /**
+   * The base plugin ID.
+   *
+   * @var string
+   */
+  protected $base_plugin_id;
...
+    $this->basePluginId = $base_plugin_id;

This doesn't seem to be needed but yeah I don't care.

+++ b/core/modules/views/lib/Drupal/views/Plugin/Derivative/ViewsBlock.phpundefined
@@ -24,6 +26,43 @@ class ViewsBlock implements DerivativeInterface {
+   * @param \Drupal\Core\Entity\EntityStorageControllerInterface $view_storage_controller
+   *   The entity storage controller to load views.
...
+  public function __construct($base_plugin_id, EntityStorageControllerInterface $view_storage_controller) {

I guess we should use the ViewStorageControllerInterface?

+++ b/core/modules/views/lib/Drupal/views/Plugin/Derivative/ViewsBlock.phpundefined
@@ -39,7 +78,7 @@ public function getDerivativeDefinition($derivative_id, array $base_plugin_defin
-    foreach (views_get_all_views() as $view) {
+    foreach ($this->viewStorageController->load() as $view) {
       // Do not return results for disabled views.

What a big amount of work for just this single change

Other than the fact that we're injecting the EntityManager when we actually need

+++ b/core/modules/views/lib/Drupal/views/Plugin/Derivative/ViewsBlock.phpundefined
@@ -24,6 +25,25 @@ class ViewsBlock implements DerivativeInterface {
+  public function __construct(EntityManager $entity_manager) {
+    $this->viewStorageController = $entity_manager->getStorageController('view');

Seems odd that we're getting the entity manager when what we actually need is the view storage controller, but perhaps this is just how it is right now. Otherwise this looks great to me.

This needs tests, and then I'd be happy to rtbc it.

Eclipse

I was pretty certain when I first skimmed the patches but now I'm a little torn. I think I much prefer the former patch over the later. It feels like it would provide a little more flexibility and I'm dubious of the utility of providing the fetcher as a service. It seem like an entirely internal object that is neither useful to other implementations or particularly swapable.

The downside though is it makes the fetcher slightly less testable because the actual used services are embedded in the container. So we're not really doing the best form of injection here.

needs work either way.

Eclipse

My review on #1 was odd/

Added some tests

Nice addition.

I'm generally ++ to this and am also RTBC. I might caution that we probably shouldn't re-invent the ContainerInterface stuff over and over and over again for different use cases, considering it's the same thing all the time. But that seems like a general followup for all of core, not Derivatives specific.

Seconding the RTBC

Eclipse

Committed bd51e51 and pushed to 8.x. Thanks!