WIP: feature: Alert users when form has unsaved changes

[coolprobn]

Description

Add a stimulus controller to track changes in the form and show alert box when user moves away from the current form, either by reloading the page or clicking any other buttons in the application with the use of Turbo Navigation.

Fixes # (issue)

Closes #673

Checklist:

• [x ] I have performed a self-review of my own code
• [x ] I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works

Screenshots & recording

https://www.loom.com/share/9bac6ed248014dfdbcc52d76b1973a99?sid=ca6389a5-eda4-41df-a357-e987a3565233

Manual review steps

Feature walkthrough is in the screen share attached above

TODO

• Add tests for the changes

[codeclimate]

Code Climate has analyzed commit 4fdbfda and detected 0 issues on this pull request.

View more on Code Climate.

[adrianthedev]

This PR is definitely in the right direction.

My wondering developer brain started to think about things.
I'm just going to add things here; feel free to ingore them.

1. Would it be difficult to capture which fields are dirty?
2. Would it be possible to "undirty" the form if the user changes the field back to the original value
3. Would it be possible (or valuable) to show a dirty state (toggleable) through a setting.

All of these kind of converge into the same thing;
to hold previous and new state in JS and compare them.

It brings quite some complexity around it with state that can get dirty from different JS plugins.

But I can't shake that feeling that if I make the form back the way it was before, I'd like the dirty state to go away and not make me anxious of why I need to save the form, or loose my changes (whichever they are).

Do you get this feeling?
Do you think it's just me?

Thanks for the great work.

[RocKhalil]

@adrianthedev jumping into the conversation cause I have other concerns regarding what you said;

what about custom fields developed by people for their own solutions ?
should the dirty state be accessible by other components to push to it ?
should relationships ( nested_attributes ) be taking into consideration ?
etc etc..

[adrianthedev]

Yes, I agree it gets deep very quickly.
Let's keep it simple.
I wonder if we could achieve that "un-dirty" use-case in a... simple way.

[coolprobn]

@adrianthedev I had a fleeting thought on what if the field is reverted back to the original state but forgot about it soon. So, I get what you are talking about.

Tracking full state and toggling the form will be way out of scope but un-dirtying should be handled in this PR. I will work on that tomorrow and also start adding tests since this is the intended feature you were looking for.

Any tip on where to start to ensure I haven't broken existing tests? Running whole suite would take a lot of time, I assume?