- 🇺🇸United States smustgrave
Was tagged for tests and change record that I believe still need to happen.
Since Drupal 8 we've done some work to remove 'magic array keys'. But we still have render arrays, which every time you use them cause you to need to look-up the allowed keys. This is really bad DX. It's not clear what the allowed keys are, or where to find them. For backend developers who don't have years of experience with the nuts and bolts of Drupal's rendering system, this is more of a learning cliff than a learning curve, and it's very discouraging.
Provide builder classes for each element type to make defining render arrays discoverable from IDEs.
before
$variables['table'] = [
'#type' => 'table',
'#header' => $headers,
'#rows' => $rows,
'#attributes' => [
'id' => $table_id,
],
'#tabledrag' => [
[
'action' => 'order',
'relationship' => 'sibling',
'group' => $weight_class,
],
],
];
after
$variables['table'] = TableElement::create()
->setHeader($headers)
->setRows($rows)
->setAttributes([
'id' => $table_id,
])
->setTableDrag([
[
'action' => 'order',
'relationship' => 'sibling',
'group' => $weight_class,
],
])->toRenderArray();
This sort of interface is a lot clearer, and borrows heavily from both Url helper and FieldDefinition stuff.
In this issue, we should only introduce a base class for these builders, plus one or two concrete implementations that we use in core, to prove they work. Then, in follow-up child issues, we can introduce more builders for the various core elements, piecemeal.
Refactor the patch in #106 to modernize it -- i.e., adding type hints -- and remove most of the builders it implements (punt to follow-ups). Keep one or two useful builders, and change core to use them where possible. Add unit or kernel test coverage. Then review and commit.
/admin/content
, check that the dropbutton display correctly
http://drupal.local/en/admin/help/contextual
, make sure the icon displays in the help textNone
Creates a new optional way to create render elements.
Needs work
10.1 ✨
Last updated
Enhances developer experience.
The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.
A change record needs to be drafted before an issue is committed. Note: Change records used to be called change notifications.
The change/bugfix cannot be fully demonstrated by automated testing, and thus requires manual testing in a variety of environments.
Used to track the progress of issues reviewed by the Drupal Needs Review Queue Initiative.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Was tagged for tests and change record that I believe still need to happen.