🐞[BUG]: Form actions calling every time, when jumping to previos or other actions

[thenaim]

Affected Package

@ngxs/form-plugin

Is this a regression?

No

Description

Can you confirm that this is how it should work or I have a bug in my code?

html

  <ion-toolbar [formGroup]="activeRegion" ngxsForm="countries.activeRegion">
    <ion-segment scrollable formControlName="region">
      <ion-segment-button *ngFor="let region of regions$ | async" [value]="region">
        <ion-label>{{region}}</ion-label>
      </ion-segment-button>
    </ion-segment>
  </ion-toolbar>

ts

export const initialState: CountriesStateModel = {
  activeRegion: {
    model: {
      region: 'Africa',
    },
    dirty: false,
    status: '',
    errors: {},
  },
};

@State<CountriesStateModel>({
  name: 'countries',
  defaults: initialState,
})
@Injectable()
export class CountriesState {}

example stackblitz

https://user-images.githubusercontent.com/45883683/117194196-79a9f280-adec-11eb-8025-a713dc444dd7.mp4

[splincode]

@markwhitfeld @arturovt what do you think, this is correct behaviour?

[markwhitfeld]

@thenaim Thank you for the very thorough reproduction. I think that this is a strange interaction between the forms and devtools plugin. In theory, when the state has been updated then the form should sync with the state and the form update actions should not fire off. If the form is updated directly then those actions should fire off (as you would see when changing the tab). This may potentially be a bug related to the devtools plugin or perhaps about the interaction between the two.

[thenaim]

@markwhitfeld Thank you for your reply. It is very inconvenient, or rather impossible, when you want to reproduce the entire state in the application.

[irowbin]

Unrelated comment deleted and moved by the moderator to a separate issue: https://github.com/ngxs/store/issues/1844#issue-1244084507

[irowbin]

Unrelated comment deleted and moved by the moderator to a separate issue: https://github.com/ngxs/store/issues/1844#issuecomment-1133770421

[arturovt]

Regarding this specific issue, I can't find any bug within the form plugin that might be causing this behavior. The plugin reacts to form events and dispatches actions; there's nothing more supernatural. Closing as not an issue (at least in the plugin).