ConfigFormBaseTrait is confusing

Created on 25 May 2015, about 10 years ago

Updated 30 July 2025, 7 days ago

Problem/Motivation

#2392319: Config objects (but not config entities) should by default be immutable → introduced ConfigFormBaseTrait, which uses a non-API approach to find a configuration factory within the object it is used, and forces developers to implement a method that exposes the names of config objects that must be mutable when retrieved through ::config().

This approach can cause problems, because objects using this trait can store their configuration factory in a property that isn't named configFactory, or have it returned by a method called getConfigFactory() instead of configFactory(). They can also provide a method called configFactory() that takes required parameters, or that returns something that is not a configuration factory. At this point we might as well use service location rather than trying to retrieve a dependency through methods like these.

The purpose of the trait is disputable as well, because its only achievement is to abstract the difference between ConfigFactoryInterface::get() and ConfigFactoryInterface::getEditable() away from developers who will not learn the difference between mutable and immutable configuration like this. On top of that the abstraction is downright unnecessary, because ConfigFactoryInterface::get() returns ImmutableConfig instances which throw exceptions when any mutation action is performed on them.

Proposed resolution

There are two options:

Remove the trait and make all forms call ConfigFactoryInterface::getEditable() directly. This improve developer experience and reduces complexity.
As an alternative, use service location to retrieve the config factory and make getEditableConfigNames() non-abstract and return an empty array by default, so developers who do not wish to use this trait can safely ignore it without having to implement an unnecessary method.

Remaining tasks

None.

User interface changes

None.

API changes

None, or a small one to revert a DX regression.

📌 Task

Status

Postponed: needs info

Version

11.0 🔥

Component

forms system

Created by

🇬🇧United Kingdom Xano Southampton

Live updates comments and jobs are added and updated live.

DX (Developer Experience)
Enhances developer experience.

stale-issue-cleanup
To track issues in the developing policy for closing stale issues, [Policy, no patch] closing older issues

Incomplete comments

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment 7 days ago →
🇺🇸United States smustgrave
Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024