One of the things we did in #1927608: Change notice: Remove the tight coupling between Block Plugins and Block Entities was shift the creation of a default render array (and the invocation of an alter on that render array) onto BlockBase::build()
. This was not the greatest thing.
- It places responsibility for dictating how the presentation layer should receive the block into the hands of the block itself. Block plugins should be concerned only with producing a) a title, b) content, and hopefully soon c) assets. They should not concern themselves with how that information is glued together and provided to the frontend. We have a BlockPluginInterface specifically so that external systems can make such decisions.
- By placing the alter inside the build method, we make it possible for blocks to individually decide whether they are alterable or not. Much though I hate that particular alter, if we're going to have it, then it needs to be invoked reliably. That means pushing the decision up to a higher layer where it can be swapped out wholesale, and is either on or off for all blocks, equally.
- If someone wants to, say, create an administrative interface in which one "renders" blocks for some alternate purpose - say, putting in dummy content in order to populate a demonstration interface - then it's easy to do by simply swapping in a different rendering controller and creating a different default render array. If the logic remains baked on the block itself, though, then we either have to ignore that method entirely, or throw out and rewrite most the render array each time...and it's hard to do that really reliably, since a particular block plugin might override BlockBase::build() and do a whole buncha wacky crap with the render array it returns.
So, this patch shifts that responsibility back out onto the BlockRenderController
. It also gets rid of the blockBuild()
method, and all block plugins now just directly implement build()
.
Note: this also makes princess happy.