The source companion shows A changing from classes panel and old, ID demo-a, and data-mode draft to classes panel and ready, no ID, and data-mode review. B retains class panel, ID demo-b, and data-mode draft. The property tables are expected results beside generated Twig; this browser page does not run Drupal.
Use the worked example
Choose Apply A operations and compare the property tables. The generated template chains addClass, removeClass, setAttribute, and removeAttribute on A, then prints A once. Reset returns the tables to their starting values. These controls switch the comparison between expected states; they do not invoke Drupal’s Attribute methods in the browser.
Follow the source and its scope
A is the element to change. B is a separately created comparison object that should remain unchanged. The generated Twig creates both objects independently from the supplied values, so you can follow the same small example in a maintained Drupal template.
{% set a = create_attribute({
'class': ['panel', 'old'],
'id': 'demo-a',
'data-mode': 'draft'
}) %}
{% set b = create_attribute({
'class': ['panel'],
'id': 'demo-b',
'data-mode': 'draft'
}) %}
The intended class membership is panel and ready. The id property is absent, rather than present with an empty value. The data-mode value is review.
The methods in the generated source belong to Drupal’s Attribute object. They are different from browser classList calls. Here, panel, old, and ready are class tokens chosen to make the change visible in the property table; no stylesheet is supplied to give ready a particular visual treatment.
Drupal's API illustrates how printing an individual class property alongside the full collection can produce duplicate class attributes. Its Attribute object collects and renders the collection. Drupal 11.x Attribute API
When you render the Twig in Drupal, compare the named properties rather than requiring one exact serialized attribute order. A should have panel and ready in a single class attribute, no id attribute, and data-mode="review". B should still have its original three properties. A browser-only expected table cannot establish the actual serialized result for that environment.
For your own element, list any additional supplied attributes before adapting the operation chain. This example has only the three starting properties shown above. Replacing a real collection with those three practice fields could lose an accessibility label, a relationship, or another attribute that your element needs to preserve.
A second variable pointing at A is not the separately created B described above. Drupal's documented methods mutate the object and return it for chaining. Treat independence as an input requirement, not as an automatic clone operation.
If a real integration shares an object intentionally, document that separately and test its consequences. Do not silently add cloning, assume a shallow copy is sufficient, or promise immutable method behavior.
The browser page offers the fixed A operation chain, not an arbitrary attribute editor. To explore a different property, change a separate copy of the Twig source and compare its rendered output with the starting attributes. Keep B independent if you are using it to detect an unintended change to another element.
The supplied chain changes fixed class tokens and the named id and data-mode attributes. Broader attribute editing needs context-specific handling: the API documentation distinguishes ordinary escaping from URI protocol handling, for example. A successful result for this fixed chain would not establish that every possible attribute name and value is appropriate.
B’s unchanged values are as important as A’s changed ones. Check both property sets when moving the source into a theme. The independent create_attribute calls are what establish this comparison; assigning a second variable to A would not provide the same independent object.
Copy a prompt for this example
Build one HTML source companion demonstrating a fixed sequence of Drupal Twig Attribute operations. The browser must display generated Twig and expected properties, clearly separate from a real Drupal render.
Generate two independently constructed objects using create_attribute. A starts with classes panel and old, id demo-a, and data-mode draft. B starts with class panel, id demo-b, and data-mode draft. Show both objects' classes, ID, and data-mode in a before-state table.
Provide Apply A operations and Reset objects buttons. Applying the example changes only A: addClass('ready'), removeClass('old'), setAttribute('data-mode','review'), and removeAttribute('id'). Expected A has class membership panel and ready, no id property, and data-mode review. B remains panel, demo-b, draft.
Print each complete collection once in the generated opening tag, with no second hand-written class attribute. Keep the output example focused on property membership rather than requiring one exact serialization order. Explain that assigning another variable to A is not the independent B construction shown here.
Reset restores both original property sets. Repeated Apply should show the same expected end state rather than accumulating another ready class. Keep an explicit statement that no Drupal or Twig engine runs on this page; a developer must check the generated template in the actual project.
Use wrapped code, readable property rows, and a small-screen layout without horizontal scrolling. Return all HTML, styling, and button logic in a single file.
Render the generated Twig in your maintained Drupal environment and compare A and B with the expected property sets. NOS can preview the prepared HTML companion for that discussion. Record the Drupal version with the actual output before relying on the operation chain in your theme.