Would be nice if the FormState object could determine whether a form's values have changed, so to say that whether it is dirty.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

_Archy_ created an issue. See original summary.

_Archy_’s picture

Status: Needs work » Needs review
FileSize
1.53 KB

Added an implementation for this. Don't know for sure, but I didn't see any way that the FormState knows about the form, so I added as a parameter the form. But it would be nice if that parameter didn't exist. If anyone has an idea. Maybe implement a way for a form state to know about the forms default values?

Tests will be added when this approach is confirmed good.

shadcn’s picture

$this->getCompleteForm(); will get you the form.

See https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Form%21Fo...

Status: Needs review » Needs work

The last submitted patch, 2: forms_system-add_is_dirty-2847821-2-D83.patch, failed testing.

_Archy_’s picture

@arshadcn for that method to return the form, it must be set first with setCompleteForm() on the form state. It isn't always set. In the context I was testing this new method it wasn't set, so to use that I would have to set it before calling isDirty().

I don't really understand all this fails for the patch. It only introduces a new method. Also checked that I made it for the right branch (8.3.x). Maybe someone can explain?

xjm’s picture

Version: 8.3.x-dev » 8.4.x-dev
tim.plunkett’s picture

In the context I was testing this new method it wasn't set

When was this? If it wasn't set, the form was not finished building, so it would be too early to check for all #default_value elements anyway, since all #process and hook_form_alters will not have run yet.

The error is:
Class Drupal\Core\Form\SubformState contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Drupal\Core\Form\FormStateInterface::isDirty)

  1. +++ b/core/lib/Drupal/Core/Form/FormState.php
    @@ -769,6 +769,29 @@ public function isSubmitted() {
    +  public function isDirty(array $form)
    +  {
    

    Nit: should be the same line

  2. +++ b/core/lib/Drupal/Core/Form/FormState.php
    @@ -769,6 +769,29 @@ public function isSubmitted() {
    +    foreach ($this->getUserInput() as $field => $value) {
    +      if (!array_key_exists($field, $form)) {
    

    This can be an infinitely nested array. Checking the form at the top level will not work here.

  3. +++ b/core/lib/Drupal/Core/Form/FormStateInterface.php
    @@ -951,6 +951,17 @@ public function setSubmitted();
    +     * Determines if the form's values differ from default.
    

    What is a use case for this?

_Archy_’s picture

Thanks for looking into this. I will think of other ways when I'll have time.

Till then I'll link the issue from which this idea came. That will explain a use case and will give you the context in which the for wasn't set on the form-state.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

_Archy_’s picture

Status: Needs work » Needs review
FileSize
5.39 KB
5.91 KB

Did some work for this. Refactored they way the checking works. Addressed comments from #7. Created tests, but only unit ones. Do we need functional ones?

_Archy_’s picture

This method of checking is not the best performance wise as it is linearly taking all elements of the form and comparing the values till it gets one that has different value. It works well if we check for all the values of the form, but when we want just a subset of fields to check it still traverses the whole form. This could be improved if there is a way of converting #parents to #array_parents, but I am not sure that is possible.

Status: Needs review » Needs work

The last submitted patch, 11: forms_system-add_is_dirty-2847821-11-D86.patch, failed testing. View results

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.