Dependent/Dynamically Visible Fields Based on Selection (Modifier Deep Dive)
Dependent/Dynamically Visible Fields Based on Selection (Modifier Deep Dive)
~9 Min. Lesezeit Zuletzt aktualisiert am August 9, 2026
Chapter 13 showed modifyMeta() as a direct but error-prone way to change field configuration. For the most common case - showing/hiding a field based on another field's value - there's a cleaner, purely declarative mechanism: imports/exports.
Practical case: company field only for "business customer"
Suppose the testimonial form gets a new boolean field is_business_customer - the company field should only be visible when that checkbox is checked. Purely declaratively via switcherConfig:
<field name="is_business_customer" formElement="checkbox">
<settings>
<valueMap>
<map name="false" xsi:type="number">0</map>
<map name="true" xsi:type="number">1</map>
</valueMap>
<dataType>boolean</dataType>
<label translate="true">Business Customer</label>
</settings>
<formElements>
<checkbox>
<settings>
<switcherConfig>
<rules>
<rule name="0">
<value>0</value>
<actions>
<action name="0">
<target>mironsoft_testimonial_form.mironsoft_testimonial_form.general.company</target>
<callback>hide</callback>
</action>
</actions>
</rule>
<rule name="1">
<value>1</value>
<actions>
<action name="0">
<target>mironsoft_testimonial_form.mironsoft_testimonial_form.general.company</target>
<callback>show</callback>
</action>
</actions>
</rule>
</rules>
<enabled>true</enabled>
</switcherConfig>
</settings>
</checkbox>
</formElements>
</field>switcherConfig reacts directly in the browser to value changes, with no server round trip at all - the target path again matches the full namespace chain from form.xml (namespace.provider.fieldset.fieldname).
When modifyMeta() is still needed
switcherConfig covers purely client-side, value-based toggling. As soon as visibility depends on server state - for example "only show the company field for testimonials that already have a company on file, not for new ones" - the modifier from chapter 13 is required, because only PHP knows at load time whether a record exists:
public function modifyMeta(array $meta): array
{
$isNewRecord = $this->request->getParam('id') === null;
$meta['general']['children']['company']['arguments']['data']['config']['visible']
= !$isNewRecord;
return $meta;
}imports/exports for data flow between fields
Besides visibility, imports/exports can also declare pure data flow between fields - for example a label that live-updates to reflect the entered customer name:
<field name="testimonial_text" formElement="textarea">
<settings>
<imports>
<link name="label">${ $.provider }:data.customer_name</link>
</imports>
<dataType>text</dataType>
<label translate="true">Testimonial Text</label>
</settings>
</field>Tipp: Rule of thumb for this series: try switcherConfig/imports/exports first whenever it's purely about client-side, value-based reactions - only switch to the modifier from chapter 13 once server state (loaded data, permissions, database lookups) drives the decision. The declarative solution is more robust against typos, since broken paths at least show up in the browser console instead of being silently ignored.