Local save tweak #30
No reviewers
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
sfb1451/z03-assessment-center-data-entry!30
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "local-save-tweak"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR closes #29 with the following changes:
Save buttons at the end were reordered (now: 1 - Daten lokal speichern, 2 - Daten speichern 3 - Lokale Daten laden).
The submit button (Daten Speichern) is now enabled only after the local save has been used. This makes local save essentially required (though there are loopholes). From the code point of view, the state of the submit button (enabled/disabled) is now tracked by a global variable pointing to an object literal, which has a a method to update. I'm not sure if that's the best way of doing so, and if you have better ones I'd be happy to rework it. The goal is to make it harder to "forget" local saving and send the data straight away, thus exiting the form (i just lacked imagination to do something other than what was literally requested).
Function-wise it looks good to me. Please consider whether you work in the comments or not.
You might want to use
setinstead oftoggle, since "toggle" ususally means to flip the logical state, i.e. to setx := not x, and you are just setting the value here.On the same note:
submitButtonTogglershould probably be something likesubmitButtonUpdaterDon't leave commented code lying around, it is hard to say how old the comment is and, in isolation, it does not provide insight on the overall structure. We have git to see what changed when. And the code should be, in the best of all worlds ;-), always so clear and structured, that the concepts can be deduced
I'll go for a more explicit
setAndUpdateto avoid collision withsetkeyword.Thanks for the review and the comments @christian-monch ! I made the suggested changes, and I'll merge.