I am about to port renderkit to Drupal 8.

The D7 version contains an interface EntityDisplayInterface, which builds render arrays from entities.

In the D7 version, this contains one method buildEntities($entity_type, $entities); which allows to process multiple entities at once. The idea here was that this could speed up performance.

For D8, I wonder if this is still relevant. E.g. it seems that D8 views really renders each entity separately. And even though there is EntityViewBuilder::viewMultiple(), this really does most of its processing within the foreach(), so separate per entity.

So.. should I drop the buildEntities() method in D8, and only leave buildEntity()?

  • Performance reasons aside, I would keep the API the same if possible so as to not confuse your userbase. :)
    – tenken
    Commented Aug 9, 2017 at 15:06
  • This is already a lost cause because the signature of those methods will inevitably change, as $entities parameter will be type-hinted with EntityInterface, and $entity_type parameter will be dropped at least for ::buildEntity().
    – donquixote
    Commented Aug 9, 2017 at 15:08
  • Also I don't know who my userbase is, or how many.. drupal.org/node/2900827
    – donquixote
    Commented Aug 9, 2017 at 15:09
  • oh ok. hmm sorry I dunno intimate details on entity rendering in d8. Ah, by userbase I ment the ~750 downloads of your module.
    – tenken
    Commented Aug 9, 2017 at 15:11
  • Just saying, I found \Drupal\Core\Entity\Display\EntityViewDisplayInterface, which looks similar to my EntityDisplayInterface, except that it has this verbose parent interface. EntityViewDisplayInterface::buildMultiple() seems to be optimized for processing multiple entities at once.
    – donquixote
    Commented Aug 9, 2017 at 20:39

1 Answer 1


buildMultiple() exists, but it was done before we introduced render caching to entities and with that, lazy entity rendering/building. Now we don't really need multiple processing.

See https://www.drupal.org/node/2843565 for a discussion about that and the conclusion that we don't really need buildMultiple() anymore.

The idea is that if we render a page with 20 articles, then rendering them all separately is slightly slower on the first request. However, if you save one of those articles, or create a new one, then when accessing that page again, only one needs to be rendered (again), the others can be returned from the cache.

Whether or not a multiple API makes sense for you depends on how it will be called, if you expect it to be called on multiple entities, then can make sense, if not, then probably not.

  • renderkit EntityDisplayInterface objects can be called in various ways. Some of them multiple, some of them single. E.g. drupal.org/project/entdisp has a Views row plugin, a Views field plugin, an entityreference formatter plugin, and then there is drupal.org/project/entdispfieldui. But the entire API would get simpler if it only supports single entity.
    – donquixote
    Commented Aug 11, 2017 at 19:18
  • Which exactly is cached? The building of the render array, or the rendering of the render array to html? Or both? I attended Fabian's session but forgot :)
    – donquixote
    Commented Aug 11, 2017 at 19:19
  • 1
    Both. See md-systems.github.io/drupal-8-caching/#/render-caching and down.
    – Berdir
    Commented Aug 11, 2017 at 20:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.