[ResponseOps][MaintenanceWindows] Move recurring schedule form to dedicated package

[umbopepato]

Summary

Moves the recurring schedule (rrule) form from the Maintenance Windows form to a dedicated package.

Implementation details

Because of the tight time constraints we have for this epic, I tried to change the recurring schedule form as little as possible, keeping the existing form-lib-based implementation and adding an intermediate layer to embed the editing UI in larger forms (i.e. MW form). While this is not particularly elegant, it allows us to build on top of an existing, tested codebase and to leverage form-lib's validation and state management capabilities.

In the context of the MW form, the recurring schedule editor is treated as a single field. Value and error updates are synced through form-lib's field hook API:

kibana/x-pack/platform/plugins/shared/alerting/public/pages/maintenance_windows/components/recurring_schedule_field.tsx

Lines 21 to 34 in acd6a48

	<UseField<RecurringSchedule, FormProps> path={path}>
	{({ value, setValue, setErrors }) => (
	<RecurringScheduleForm
	recurringSchedule={value}
	onRecurringScheduleChange={setValue}
	onErrorsChange={(errors) => {
	setErrors(errors.map((message) => ({ path, message })));
	}}
	startDate={startDate}
	endDate={endDate}
	timezone={timezone}
	/>
	)}
	</UseField>

Errors are handled internally by the schedule editor, but must still be surfaced up to the parent form in order to have a consistent validity state (otherwise submits are not prevented even if errors are shown in the UI).

The recurring schedule form schema and form fields are exported to be reused in larger form-lib forms.

References

Closes #219454

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[adcoelho]

Suggested change

	await waitFor(() => expect(screen.getByTestId('bymonth-field')).toBeInTheDocument());
	expect(await screen.findByTestId('bymonth-field')).toBeInTheDocument();

[adcoelho]

I tried to change the recurring schedule form as little as possible, keeping the existing form-lib-based implementation and adding an intermediate layer to embed the editing UI in larger forms (i.e., MW form). While this is not particularly elegant, it allows us to build on top of an existing, tested codebase and to leverage form-lib's validation and state management capabilities.

I am still a bit unsure about this.

I'll up my conclusions after reading the code, and let me know if they are right:

1. RecurringSchedule was previously used in MW
2. RecurringSchedule used to be just a wrapper around multiple UseFields.
3. RecurringSchedule was moved to a package and wrapped in <Form>.

Now, in MW we have something like:

<Form> // <CreateMaintenanceWindowForm>
    ...
    <ABunchOfOtherFields>
    ...
    <UseField> // <RecurringScheduleField> 
        <Form> // <RecurringScheduleForm> 
            <UseField> // the same as the previous RecurringSchedule implementation
            ...

I'm not sure I like the Form > UseField > Form approach, or rather, I'm unsure what to expect in its behavior.

For example, the recurringSchedule schema was removed from maintenance_windows/components/schema.ts, which now comes from RecurringScheduleForm. What should be expected when submitting CreateMaintenanceWindowForm?

Validation appears to be working fine(I tested the PR a bit), but maybe there is a simpler solution.

Why not split RecurringScheduleForm in the package into Form and Fields, and import here only the fields(similar to what was done before)?

[js-jankisalvi]

I'm not sure I like the Form > UseField > Form approach, I'm unsure what to expect in its behavior.

+1 on that. This would be a simpler solution to have Fields (frequency, interval etc.) as one component which could be used in RecurringScheduleForm and imported to MW and used directly in CreateMaintenanceWindowForm.

[umbopepato]

Although not very elegant, the intention was to hide the form lib editing functionality inside the schedule component and just expose a value/onChange prop API to the exterior so the same component could be used in other types of forms or editing UIs too. Since all the forms that use this schedule fields are currently all form-lib-based, and you too have doubts on the encapsulated solution, I switched to exporting the schema and the fields separately. We can always move to a more generic solution later if needed.

[js-jankisalvi]

Verified locally, works as expected. Had only one concern about wrapping a form inside field mentioned above

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 32b1f7d

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
alerting	216	219	+3

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
alerting	91.2KB	91.4KB	+181.0B

Unknown metric groups

ESLint disabled line counts

id	before	after	diff
@kbn/response-ops-recurring-schedule-form	-	1	+1

Total ESLint disabled count

id	before	after	diff
@kbn/response-ops-recurring-schedule-form	-	1	+1

History

• 💚 Build #302763 succeeded 74ed4de
• 💛 Build #299878 was flaky 04a8a40
• 💔 Build #299816 failed abaecf3
• 💔 Build #299797 failed f046fb3

[kibanamachine]

Starting backport for target branches: 8.19

https://github.com/elastic/kibana/actions/runs/15554987050

[kibanamachine]

💔 All backports failed

Status	Branch	Result
❌	8.19	Backport failed because of merge conflicts

Manual backport

To create the backport manually run:

node scripts/backport --pr 220535

Questions ?

Please refer to the Backport tool documentation

[umbopepato]

💚 All backports created successfully

Status	Branch	Result
✅	8.19

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation