fix: create new event - save button not working

[MatiasArriola]

Related Issue: https://app.clickup.com/t/86987atgk

Problem: Save button is unresponsive / does nothing

Cause: In withSaveHandler.js the sectionsInitialised prop is false, preventing the call to validateAndSave.

sectionsInitialized returns false in case there is any element in the redux state formsSectionsFieldsUI.singleEvent-newEvent[dataElementId] that does not have the valid key.

It was observed that under some conditions, dataElements were left out without its valid flag, causing the form to incorrectly not be "initialized", thus preventing save and causing a confusing behavior. Two different scenarios for this behavior were identified.

These valid flags are updated after any field change (or just focus/blur), that triggers the rule engine execution.

The UI does not give any feedback about pending validations, and some elements may get stuck never getting validated.

Other confusing scenario is that clicking save does nothing, then after changing a field, the save would trigger (without clicking save again), since waitForFieldValidations state becomes false after sectionsInitializedbecomes true. (withSaveHandler#componentDidUpdate).

---

Cause 1: Navigation and actions dispatched in an incorrect order

It is expected that the redux actions are dispatched in the following order to get the expected state:
1 - loadNewDataEntry
2 - updateRulesEffect

However, if you are in the list view, create new event, go back to the list, and create a new event again, updateRulesEffect would trigger before loadNewDataEntry. This leads to unexpected state.

Initial load:

After navigation:

loadNewDataEntry is dispatched after updateRulesEffect and between other actions.

It would eventually sort itself after some field changes that trigger UpdateRulesEffects, but inbetween It could lead to the "save not working" issue.

Cause: useRulesEngine hook is a useEffect that triggers the updateRulesEffect, but since formFoundation is cached in subsequent uses, it is triggered before loadNewDataEntry.
Fix: 699793c Workaround adding a flag based on the observed state, to prevent dispatching the event earlier.
Change risk: low/moderate. This hook is only used in NewEventDataEntryWrapper.component.js

Cause 2: HIDEFIELD inside HIDESECTION programRuleActions

In our instance we had two specific dataElements that were left "orphaned", without setting its valid property in the formsSectionsFieldsUI state.
These two fields were targeted by HIDEFIELD actions, and also included in sections targeted by HIDESECTION actions.
The form would only allow saving when the HIDEFIELD action is triggered. Otherwise it would never be updated with the valid flag.

Cause:
When the form first loads, it triggers UpdateRulesEffects which includes in the payload a HIDEFIELD and an ASSIGN null for the dataElement. This adds the dataElement to the formsSectionsFieldsUIstate with only the property { touched: true } (as with the rest of the dataElements). This is coming from the useRulesEngine hook.

After any change to a field, UpdateRulesEffectsis triggered again, but this time as part of the RulesEffectsForNewSingleEventActionsBatch. This is triggered in capture-core/components/DataEntries/SingleEventRegistrationEntry/DataEntryWrapper/DataEntry/epics/newEventDataEntry.epics.js#runRulesForNewSingleEvent
This time, validations are run, and the valid flag is set for each dataElement.

For the affected dataElements, the ASSIGN effect would not be included if the HIDEFIELD action condition is not met (but still hidden by its parent section - its valid prop is not set).

Fix: 4b1dbc7 include all hidefield effects (with the ones from HIDESECTION) when calculating the subsequent assign effects, so later the dataElement can be validated.
Change risk: high. This is a core function.

Closing thoughts

These changes are just workarounds that need thorough testing (especially "cause 2" fix).
Better fixes that would imply bigger changes might be:

1. Stop using valid prop as a mean to check if validations are complete, and use other piece of state or signaling for sectionsInitialized and waitForFieldValidations in order to avoid similar issues in the future.
2. Use the same logic at initial load and subsequent field updates to generate the payload for UpdateRulesEffects.

Sorry for the long text! Will update if anything can be further clarified and or simplified

[anagperal]

thanks @MatiasArriola ! [code-only review]