[ML] Transform: Use redux toolkit for state management for edit transform flyout

[walterra]

Summary

Part of #151664.

This replaces the state management of the edit transform flyout with Redux Toolkit (which is already part of Kibana's package.json). Previously, we avoided redux because of the additional boilerplate. However, Redux Toolkit provides utilities (e.g. createSlice, immutable state updates via immer) that significantly reduce the necessary boilerplate. For example, there is no longer a need to write classic action creators or even a reducer. In fact, this PR gets rid of action reactors and the reducer that were mimicking classic redux behaviour. If you know a bit of old plain boilerplaty redux, have a look here how it looks with Redux Toolkit: https://redux-toolkit.js.org/tutorials/quick-start (look out for the counterSlice part, that explain the main difference to writing old school action creators and reducers).

So instead of a full reducer and corresponding action definitions, we can now write more simple callbacks that will end up as reducer actions being automatically set up via createSlice:

const setApiError = (state: State, action: PayloadAction<string | undefined>) => {
  state.apiErrorMessage = action.payload;
};

Note that under the hood redux toolkit uses immer which allows us to write the above shorter notation, it let's us treat immutable state updates as if we're mutating state. Otherwise we'd have to write the following to be returned from the action:

({
    ...state,
    apiErrorMessage: action.payload
})

This becomes even more useful for otherwise painful nested state updates. Here's a nice reference on how to do various types of state updates with immer: https://immerjs.github.io/immer/update-patterns/

On the other hand, to consume data from the redux store, we use so-called selectors. Under the hood they are optimized to avoid unnecessary rerenders or even render loops, something we especially had to work around in the state management of the transform creation wizard with custom state comparison. Simple selector setup and usage would look like this:

// state.ts
export const selectApiErrorMessage = (s: State) => s.apiErrorMessage;
export const useApiErrorMessage = () => useSelector(selectApiErrorMessage);

// component.tsx
export const ApiErrorCallout: FC = () => {
    const apiErrorMessage = useApiErrorMessage();
    return <p>{apiErrorMessage}</p>;
}

It's certainly possible and you might be tempted to write these simple selectors inline like useSelector((s: State) => s.apiErrorMessage). However, note that you'd then still have to pass around the State type. And you might quickly lose track of which state attributes you use across your components. Keeping the selector code close to where you manage state will help with maintainability and testing.

Be aware that as soon as you require local state in components derived from more than one redux store attribute or including more complex transformations, you might again run into unnecessary rerenders. To work around this, redux toolkit includes the reselect library's createSelector. This will allow you to write selectors with proper memoization. They work a bit like the map-reduce pattern: As the map part you'll select multiple attributes from your state and the reduce part will return data derived from these state attributes. Think of it as a map-reduce-like subscription to your store. For example, prior to this PR, we set the isFormValid attribute actively as part of the update actions in the form's state. This new version no longer has isFormValid as a state attribute, instead it is derived from the form's field statuses as part of a selector and we "subscribe" to it using useSelector().

// state.ts
const isFormValid = (formFields: FormFieldsState) =>
  Object.values(formFields).every((d) => d.errorMessages.length === 0);
const selectIsFormValid = createSelector((state: State) => state.formFields, isFormValid);
export const useIsFormValid = () => useSelector(selectIsFormValid);

// component.tsx
export const UpdateTransform: FC = () => {
    const isFormValid = useIsFormValid();
    ....
}

In the above code, the isFormValid() function in state.ts is the same code we used previously to actively verify on state actions. However, this approach was more risky because we could miss adding that check on a new state action. Instead, selectIsFormValid sets us up to switch to the more subscription like pattern. For createSelector, the first argument state: State) => state.formFields just picks formFields (= map step), the second argument passes isFormValid to do the actual validation (= reduce step). Finally, for more convenience we wrap everything in a custom hook useIsFormValid. This way the consuming component ends up really simple, all with proper memoization in place.

Memoization gets a bit more tricky if we want to combine selectors with information we have only available as props or via react context. For example, the wrapping component of the flyout to edit transforms provides the original transform config and an optional dataViewId. If we want to find out if a user changed the form, we need to compare the form state to the original transform config. The following code sets us up to achieve that with memoization:

// state.ts
const createSelectIsFormTouched = (originalConfig: TransformConfigUnion) =>
  createSelector(
    (state: State) => state.formFields,
    (state: State) => state.formSections,
    (formFields, formSections) => isFormTouched(originalConfig, formFields, formSections)
  );
export const useIsFormTouched = () => {
  const { config } = useEditTransformFlyoutContext();
  const selectIsFormTouched = useMemo(() => createSelectIsFormTouched(config), [config]);
  return useSelector(selectIsFormTouched);
};

// component.tsx
export const UpdateTransform: FC = () => {
    const isFormTouched = useIsFormTouched();
    ....
}

createSelectIsFormTouched is a factory that takes the original transform config and returns a selector that uses it to verify if the form state changed from the original config (That's what's called currying: A function returning another function, where the args of the first function get set in stone and are available to the scope of the second function). To properly memoize this, the custom hook useIsFormTouched() puts this factory inside a useMemo so the selector would only change once the original config changes. Then that memoized selector gets passed on to useSelector. Again, the code in the component itself ends up being really simple. For more examples on how to write proper memoized selectors, have a look here: https://github.com/amsterdamharu/selectors

Checklist

• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

Pinging @elastic/ml-ui (:ml)

[peteharverson]

Tested with a variety of edits for batch and continuous transforms and LGTM

[qn895]

Nit: Doesn't look like we are using selectRetentionPolicyField outside of this file. No need to export.

[qn895]

Thought but not blocking: Might be more descriptive to name the folder hooks (or hooks and selectors (?)) instead of selectors since that's what we are mainly exporting. Whether we are using selectors under the hood is an implementation detail.

[walterra]

I was going back and forth regarding this too. I'll leave it as is for now but will revisit in a follow up.

[qn895]

For future follow ups: Would be good to have unit tests for this function

[walterra]

We don't have dedicated unit tests for this file yet but applyFormStateToTransformConfig() exclusively makes use of this function and is covered by unit tests. I plan to move the code related to these form utilities to a package and will add more tests as part of that move. Updated the issue in that regard tracking the redux migration: #151664

[qn895]

Tested and LGTM other than the non-blocking nit comments.

[darnautov]

nit: useMount, so it's clear the callback should invoke only on mount and we can omit // eslint-disable-next-line react-hooks/exhaustive-deps

[walterra]

👍 updated in 31d5d15.

[darnautov]

LGTM

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 31d5d15

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
transform	405	421	+16

Async chunks

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

id	before	after	diff
transform	402.9KB	402.5KB	-444.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
transform	18.2KB	18.4KB	+161.0B

History

• 💛 Build #187585 was flaky ca3467b
• 💚 Build #186285 succeeded af818e6
• 💔 Build #186092 failed 2c87b051f0a16c0196a4a9f86048618212a16803
• 💔 Build #185800 failed 5116854145908b53be98ae591635d6bc03789cc0
• 💚 Build #185663 succeeded 662287733079b63432afbb9561f4d6b5cfada450
• 💔 Build #185624 failed 1be4bae4ba3abed9d32f7f6d886102077ae74df9

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @walterra