[ML] Adds redux toolkit example for response_stream to developer examples.

[walterra]

Summary

Follow up to #132590.
Part of #181111.

This updates the developer examples for @kbn/ml-response-stream to include a variant with a full Redux Toolkit setup. For this case, the @kbn/ml-response-stream now includes a generic slice streamSlice that can be used. This allows the actions created to be streamed via NDJSON to be shared across server and client.

Functional tests for the examples were added too. To run these tests you can use the following commands:

# Start the test server (can continue running)
node scripts/functional_tests_server.js --config test/examples/config.js
# Start a test run
node scripts/functional_test_runner.js --config test/examples/config.js

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)

[qn895]

super duper nit: I think a switch statement would be more readable here

[walterra]

updated in 737bdfd.

[qn895]

getInitialState() will be called every render here even though it's already been used to create the reducer initially. Is that what we want?

[walterra]

updated in 73d148a.

[qn895]

Code LGTM 🎉

[alvarezmelissa87]

Should there be a way to clear out errors other than the reset?

[walterra]

The example UI doesn't have an option for that, so it's not necessary.

[alvarezmelissa87]

Looks good overall. The only thing I noticed when using the example stream was that, when the 'simulate error' box was checked the error toasts only showed up sometimes. The stream always stopped at some point but the error toast only showed up maybe every other time. Saw this for both the Redux Toolkit stream and the useReducer stream. Not sure if that's expected.

[walterra]

@alvarezmelissa87 great question and finding about an error not triggering a toast. Had to read/understand again myself since it's been a while since I wrote that pattern.

On the server side we have these two parts:

              case 'throw-error':
                // Throw an error. It should not crash Kibana!
                // It should be caught and logged to the Kibana server console.
                throw new Error('There was a (simulated) server side error!');

              case 'emit-error':
                // Emit an error as a stream action.
                push(error('(Simulated) error pushed to the stream'));
                return;

So the first case throws an error server side, but it will not be propagated to the client side, because a HTTP stream can only return an error on the initial return (that would be something instead of return response.ok(responseWithHeaders);, for example if a user doesn't have enough permissions or similar). You'll just see an error on the Kibana server log via throw. The code for this example plugin is written this way to highlight the different behaviors for an error that's thrown and one that's pushed to the stream. I updated the comments in the example code to clarify.

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: c15ee16

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
aiops	610	612	+2

History

• 💛 Build #211131 was flaky fb1563a
• 💛 Build #210454 was flaky c03a427

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

cc @walterra

[alvarezmelissa87]

LGTM ⚡