Use the builder pattern to make it easier to create render arrays

Was tagged for tests and change record that I believe still need to happen.

PHP has evolved a lot since this issue was created. Type hints, property promotion, named arguments, etc. So instead of builders we can create value objects. It'll give same DX in modern IDEs.

Builder

$variables['table'] = TableElement::create()
  ->setHeader($headers)
  ->setRows($rows)
  ->setAttributes(['id' => $table_id])
  ->setTableDrag([
    [
      'action' => 'order',
      'relationship' => 'sibling',
      'group' => $weight_class,
    ],
  ],
)->toRenderArray();

Constructor

$variables['table'] = new TableElement(
  header: $headers,
  rows: $rows,
  attributes: ['id' => $table_id],
  tableDrag: [
    [
      'action' => 'order',
      'relationship' => 'sibling',
      'group' => $weight_class,
    ],
  ],
)->toRenderArray();

Overall, this will only mitigate the problem. Dropping render arrays is the only way to fully resolve the issue. I’ve filed a ticket in the ideas queue.

Added change record based on the current issue description.

@chi Re: #143 Good point. But this seems like a major step/ leap forward. I hope this issue be completed as-is as a first step?

@oily The are dozens different render elements in Drupal core. The MR currently covers just a few ones.

if people want to go ahead with this -- and I am not saying they either should or they should not, I absolutely have no opinion, I do not event want have an opinion -- then, if someone wanted the opinion of an old ghost then #142 is the way because then it's possible to add a reflection based fromRenderable somewhere (ElementInfoManager would be my guess) so that form alter does not need to deal with arrays either. Otherwise, people would need to learn both syntax to be able to debug code.

Yes, agree #142 is nicer and it also gels with some thinking I had in this experiment

It also means we might not have to add new classes for everything, we could possibly use the existing render element plugins but instantiate them.

#2702061-106: Unify & simplify render & theme system: component-based rendering (enables pattern library, style guides, interface previews, client-side re-rendering) → and downwards is relevant, but the most likely outcome would be that the number of different elements is reduced, and eventually #theme gets dropped in favour of #type component, but don't really see any reason that this couldn't all be worked on in parallel without explicit dependencies.