Do ModalNotifications trigger redispatches or block anything?

I have a Saga which listens to the FormEngineEvent “VALUE_CHANGE” for my Datepicker, which works fine.
However if this Saga dispatches an action to create a ModalNotification Activity weird things start to happen:
The original FormEngineEvent “VALUE_CHANGE” is dispatched once again but with the old values (the old stored values and not the changes like in the first “value changed” action).
Does adding a ModalNotification trigger any redispatches or block anything to explain this behaviour?

See the code below:

import { Action } from "typescript-fsa";
import { Activity, ActivityActions } from "@com.mgmtp.a12.client/client-core/lib/core/activity";
import { ApplicationSaga } from "@com.mgmtp.a12.client/client-core/lib/core/application";
import { put, take } from "redux-saga/effects";
import { SagaIterator } from "redux-saga";
import {
    ModalNotification, ModalNotificationProps
} from "@com.mgmtp.a12.widgets/widgets-core/lib/modal-notification";

export const setZuarbeitDateRangesSaga = (): ApplicationSaga.Descriptor[] => {
    return [
        {
            canHandle: (ad: Activity.Descriptor, action: Action<{}>) => {
                return (
                    action.type == "Activity/FORM-ENGINE-EVENT" &&
                    (action.payload as any).engineEvent?.type == "form-engine/event/VALUE_CHANGE" &&
                    ("officialDateRange" == (action.payload as any).engineEvent?.payload?.path[2]?.elementName)
                );
            },
            handle: (action: Action<any>) => {
                return setZuarbeitDateRanges(action);
            }
        }
    ];
};

function* setZuarbeitDateRanges(action: any): SagaIterator {
    yield take(ActivityActions.setData)
    yield take(ActivityActions.setDirty)
    yield put(ActivityActions.create({
        activityId: "MODAL_CONFIRMATION",
        loadingState: "without",
        activityDescriptor: { view: "ModalNotificationView" },
        data: {
            title: "",
            message: "",
            buttons: [],
            variant: "warning",
        }
    }));

}

export function ModalNotificationView2(
    props: ModalNotificationProps
): JSX.Element | null {
    const { children, ...modalProps } = props;
    return (
        <ModalNotification {...modalProps} padding={18}>
            {children}
        </ModalNotification>
    );
}

A Screenshot how it looks like in the store. As I said, the second FormEngineEvent after the ModalNotification-Push shouldn´t be there and only appears if the ModalNotifcation is created.

Hi @werther-veiled-cliff,

It seems to be related to the blur of the input due to opening the modal (which will change focus in the same tick).
For example if you add yield* delay(0) (from typed-redux-saga) before creating your activity the VALUE_CHANGE is not dispatched another time.

I have no other solution then moving the activity creation into the next tick by using a timeout like above. I can imagine that you can also implement some specific onBlur logic for the TextLineStateless (via WidgetMap) used inside the DateControl element of the form engine. But the details depend on your use-case.

I also had a look into your example and made some notes that you may check:

  • please use typed-redux-saga package for your effects (put, take)
  • use AnyAction from typescript-fsa package in cases you don’t know the type of the provided action
  • change your can handle to use match operators of provided form engine action types FormEngineActions.event.match(action) and Events.valueChange.match(action.payload.engineEvent)
  • you use an ApplicationSaga for overridePlatformSagas of App Setup in here instead of a customSagas regular SagaIterator, is this on purpose?
  • ActivityActions.setDirty is only triggered for initial value change of your open form (so whenever an other field is changed before this take effect is waiting endless)

Hello @markus-agile-fog,

thank you so much for answering.
Adding the “yield delay(0)” before the ModalActivity action actually solved it for me (y) Thank you :slight_smile: (y)
P.S: Thank you also for the additional tips. The code snipped above is a playground where I had been experimenting with the problem. ActivityActions.setDirty I added hoping this could give me some kind of a timeout and we normally use AnyAction. I will, however, take a look into typed-redux-saga.

Many thanks,
Werther