Refactor setupEditor effects to actions

[nerrad]

Description

This moves the setupEditor effects in the core/editor store into action-generators. Pretty straightforward change.

Also removes redux-multi dependency because setupEditor was the only effect using it.

How has this been tested?

• unit test modifications/ensure they pass.
• Manual testing of various editor states to ensure behaviour hasn't changed
• ensure no e2e breakage

Screenshots

Types of changes

Non-breaking enhancement.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[aduth]

In some ways this can be considered a blocker for #14367, as otherwise the creation of a separate registry doesn't account for the custom middlewares we apply; one of which being refx. In other words, we either need some other way to include those middlewares in the copied registry store, or to eliminate the middlewares altogether. My preference (supported by this pull request) would be the latter.

I'm experimenting with your commits cherry-picked into a local variation of #14367, and will circle back here with those findings supporting a review.

[aduth]

I suspect that this was the only occurrence of an array-action for which we apply the redux-multi middleware (i.e. upon confirmation, it may be warranted to remove as part of these changes).

[nerrad]

Sorry I don't follow: The refactor changed this from an array action to dispatch actions. So the work in this pull already removes the reliance on the redux-multi middleware for setupEditor? Or do you mean that we can remove the redux-multi dependency because of this (which makes sense).

[aduth]

Or do you mean that we can remove the redux-multi dependency because of this (which makes sense).

Yes, this.

[nerrad]

Doesn't look like anything else was using this in the editor package so went ahead and removed it. I think I did things correctly (just removed from package.json) but with this being a mono-repo I'm not sure :)

removed in 52af9b3

[aduth]

I think I did things correctly (just removed from package.json) but with this being a mono-repo I'm not sure :)

The one-line removal from package-lock.json seems correct since it's still a dependency in block-editor (though perhaps it shouldn't be; a point outside the scope of this pull request).

In any case, Travis would have caught it anyways if it was an issue, and it appears to be just fine.

[nerrad]

or to eliminate the middlewares altogether. My preference (supported by this pull request) would be the latter.

Ya that would be mine as well. Keeping the dependency tree as small as possible is a good goal.

[aduth]

Lovely 👍

(Though I'd still recommend to optionally consider my review notes)

[aduth]

Nit: I'd wondered if JSDoc had some option to document generator function yields. It appears @yields is a thing, a suitable replacement for @return.

http://usejsdoc.org/tags-yields.html

[nerrad]

Ya I had thought about using @yields but the difficulty here is that most if not all of these actions do not have a single yield. So it's a bit tricky knowing what exactly to document.

I've sort of loosely followed the pattern of only include a @return tag on generators when there are return values in the generator, otherwise having nothing.

[oandregal]

Added @yields as a feature request for the docgen default formatter: #14583