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

CommentFileSizeAuthor
#11 interdiff_2-11.txt5.91 KB_Archy_
#11 forms_system-add_is_dirty-2847821-11-D86.patch5.39 KB_Archy_
#2 forms_system-add_is_dirty-2847821-2-D83.patch1.53 KB_Archy_

Comments

_Archy_ created an issue. See original summary.

_Archy_’s picture

_Archy_ commented
Status: Needs work » Needs review
StatusFileSize
new forms_system-add_is_dirty-2847821-2-D83.patch1.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

shadcn commented

$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

_Archy_ commented

@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

xjm
she/her
Primary language English
commented
Version: 8.3.x-dev » 8.4.x-dev
tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented

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

_Archy_ commented
Related issues: +#2833388: Reset button shows on exposed filter defaults

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

_Archy_ commented
Status: Needs work » Needs review
StatusFileSize
new forms_system-add_is_dirty-2847821-11-D86.patch5.39 KB
new interdiff_2-11.txt5.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

_Archy_ commented

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.

smustgrave’s picture

smustgrave commented
Status: Needs work » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. 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!

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.