Not passing an input to a root form can trigger unexpected behavior in some cases

[maxime1992]

In both

v5:

ngx-sub-form/projects/ngx-sub-form/src/lib/ngx-root-form.component.ts

Line 46 in b8890b8

filter(newValue => !isEqual(newValue, this.formGroup.value)),

And v6:

ngx-sub-form/projects/ngx-sub-form/src/lib/ngx-sub-form.ts

Lines 151 to 167 in 274420a

	return options.manualSave$.pipe(
	withLatestFrom(formGroup.valueChanges),
	map(([_, formValue]) => formValue),
	delay(0),
	filter(formValue => formGroup.valid && !isEqual(transformedValue, formValue)),
	);
	} else {
	if (options.handleEmissionRate) {
	return formGroup.valueChanges.pipe(
	options.handleEmissionRate,
	delay(0),
	filter(formValue => formGroup.valid && !isEqual(transformedValue, formValue)),
	);
	} else {
	return formGroup.valueChanges.pipe(
	delay(0),
	filter(formValue => formGroup.valid && !isEqual(transformedValue, formValue)),

We do a check on the equality between the previous value of the form and the current one.

If we do not bind the input of a root form (in the case where we care only about the output like a filter) then the old value is never up to date and we can never emit again the default value (which is the case when we clear up the only value changed).

(as an internal reference within our CloudNC repo, @zakhenry check the commit 67be1969d14393ad4d7b4964ca68789f0b539f20 which contains the fix I raised about a month ago for our filter component)

In order to go around this, the input is required and whenever the output of the root form changes, it should come back as the input of it asap. Hence why I'm worried of #196

Not sure what we want to do here though, any idea is welcome.

[zakhenry]

I kinda feel like that is a bug then - the input should be optional, and if omitted maybe it needs to be rebound to the output

[zakhenry]

as in (pseudocode)

(
input$: Observable<T> = output$,
) {}