Enforce fine-grained form and flow validation

[ohltyler]

Description

This PR improves the overall validation logic on the workflow editor:

• moves the save/launch buttons from the global page to embedded within the editor, and adds a delete button at the global level. This is a placeholder and may be modified or removed in the future pending final UX design.
• integrates the form state in each drag-and-drop component as part of the overall validation when clicking Save button. This is done by propagating callback fn onFormChange to the low-level form components, and performing form validation and submission when clicking Save button
• adds callouts if something is invalid. separate messaging for form state vs. flow state is supported (final design/wording is TBD)
• refactors the generation of the workspaceFlowState from workspace to parent component resizableWorkspace. This allows us to perform validation in a consistent way, and pass the same, updated workflow to all downstream components.
• cleans up and simplifies saveWorkflow to perform only save/update

Additional changes:

• nit change to always default to 'manage' tab on base Workflows page for consistency
• remove placeholder Submit button since we have the logic available in the Save button now

Note that the form validation logic is complete - however, the flow validation logic is still in TODO state; for now, it always succeeds / is valid.

Screenshots:

Form validation:

Flow validation:

Demo videos:

Form validation integrated with Save button being disabled/enabled depending on unsaved changes. Note that on submitting / clicking Save, all invalid fields are highlighted appropriately, across all components. And, once everything is valid, the callout does not appear when saving.

screen-capture (18).webm

Flow validation integrated with Save button being disabled/enabled depending on unsaved changes. Ignore the callout as that logic is still a placeholder.

screen-capture (19).webm

Issues Resolved

Resolves #5

Check List

• [x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 21.39%. Comparing base (83835c2) to head (439b05f).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #114 +/- ## ========================================== + Coverage 20.20% 21.39% +1.19% ========================================== Files 54 54 Lines 797 818 +21 Branches 74 79 +5 ========================================== + Hits 161 175 +14 - Misses 630 639 +9 + Partials 6 4 -2 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[amitgalitz]

We will we use the backend validation here also in the future when saving?

[amitgalitz]

Also will we have the first save be a create basically then update?

[ohltyler]

We will we use the backend validation here also in the future when saving?

Definitely, the way I envision it is a 3-layer validation. First is basic form validation (no missing fields), second is flow validation (a DAG), and third would be backend validation. Whether we have it proactive (validation API) or reactive, we can support any way.

Also will we have the first save be a create basically then update?

Yes: https://github.com/opensearch-project/dashboards-flow-framework/blob/main/public/pages/workflow_detail/utils/utils.ts#L29:L33

[amitgalitz]

We will we use the backend validation here also in the future when saving?

Definitely, the way I envision it is a 3-layer validation. First is basic form validation (no missing fields), second is flow validation (a DAG), and third would be backend validation. Whether we have it proactive (validation API) or reactive, we can support any way.

Also will we have the first save be a create basically then update?

Yes: https://github.com/opensearch-project/dashboards-flow-framework/blob/main/public/pages/workflow_detail/utils/utils.ts#L29:L33

looks good to me, might want to revisit when we have those integrated how the save functionality will look like with the different validation, since as you commented save = create or update and launch is provision I assume. wonder if we should have differentiation for just quick create and launch too, or like we force to save and then launch, and obvious that the first save is equal to create

[ohltyler]

We will we use the backend validation here also in the future when saving?

Definitely, the way I envision it is a 3-layer validation. First is basic form validation (no missing fields), second is flow validation (a DAG), and third would be backend validation. Whether we have it proactive (validation API) or reactive, we can support any way.

Also will we have the first save be a create basically then update?

Yes: https://github.com/opensearch-project/dashboards-flow-framework/blob/main/public/pages/workflow_detail/utils/utils.ts#L29:L33

looks good to me, might want to revisit when we have those integrated how the save functionality will look like with the different validation, since as you commented save = create or update and launch is provision I assume. wonder if we should have differentiation for just quick create and launch too, or like we force to save and then launch, and obvious that the first save is equal to create

Right this will all need to be revisited when things are more finalized, for now we have placeholders and TODOs in code. This is just incremental.