FEA-1258: Named redux devtools instances

[matthewnitschke-wk]

Motivation

As its currently implemented, we have no way to provide options to the initialization of the overReactReduxDevToolsMiddleware. This pr adds an additional overReactReduxDevToolsMiddlewareFactory which currently only accepts a name parameter (more can be added as needed)

This directly proxies the list of available options which the redux-devtools api provides

Changes

• exposes new overReactReduxDevToolsMiddlewareFactory to allow constructing a dev tools middleware with a name parameter

Release Notes

Add overReactReduxDevToolsMiddlewareFactory which allows constructing redux dev tools with options

Review

Please review:

QA Checklist

• Tests were updated and provide good coverage of the changeset and other affected code
• Manual testing was performed if needed
  • Steps from PR author:
  • Anything falling under manual testing criteria outlined in CONTRIBUTING.md

Merge Checklist

While we perform many automated checks before auto-merging, some manual checks are needed:

• A Frontend Frameworks Design member has reviewed these changes
• There are no unaddressed comments - this check can be automated if reviewers use the "Request Changes" feature
• For release PRs - Version metadata in Rosie comment is correct

[aviary-wf]

Security Insights

No security relevant content was detected by automated scans.

Action Items

• Review PR for security impact; comment "security review required" if needed or unsure
• Verify aviary.yaml coverage of security relevant code

---

Questions or Comments? Reach out on Slack: #support-infosec.

[greglittlefield-wf]

A couple small things, otherwise looks good to me!

I tried locally (after applying that options default value) with multiple stores and it worked like a charm!

[greglittlefield-wf]

I almost wonder if we should deprecate this in favor of overReactReduxDevToolsMiddlewareFactory, to encourage people to add names. Thoughts?

[matthewnitschke-wk]

Maybe eventually

Technically this approach of a middleware factory is not the method that the official redux-devtools uses. Their implementation looks a bit more like:

const composeEnhancers = composeWithDevTools(options);
const store = createStore(
  reducer,
  /* preloadedState, */ composeEnhancers(
    applyMiddleware(...middleware)
    // other store enhancers if any
  )
);

I wasn't sure of the core reasoning behind this, so I felt a bit more comfortable "trying this out" for a bit before we consider it the de-facto way to initialize a dev tools middleware.

If you don't think that's necessary, I'm happy to deprecate and encourage the factory approach

[greglittlefield-wf]

That's fine by me 👍

[autobot-wf]

Skynet test results failed initially for this build but were approved by greg.littlefield
https://wf-skynet-hrd.appspot.com/apps/test/smithy/4224131/1
Approval message: only analyzer dev channel build is failing; we can ignore for now

[greglittlefield-wf]

• Changes look good
• Stores and all their actions show up separately in the dev tools when
  • one store is named and the other is not
  • both stores are named

+10

@Workiva/release-management-p

[rmconsole-wf]

+1 from RM