Turn Flux Action Creators into Redux ones

[ockham]

Convert lib/themes/actions.js to Redux-style action creators
(using redux-thunk for async actions, and redux-analytics
middleware for actions involving analytics).

Note that the themes-last-event reducer and store are removed,
as the information they hold can be obtained from the themes-list
reducer, while the analytics functionality is now implemented in
lib/themes/middlewares.

Props @mcsf

CC @ehg @seear

To test:

• Restart Calypso.
• Check that the Theme Showcase (calypso.localhost:3000/design) still works as it should, including multi-site, single-site wpcom, and single-site Jetpack views.
• Don't forget to test analytics (Enter localStorage.setItem( 'debug', 'calypso:analytics' ); in the browser console, and reload) -- themes search and activation should trigger corresponding analytics events. Check that the correct search_term is recorded. (Be aware of Search term not tracked when activating a theme from multisite #391, though -- search_term isn't properly recorded for activation or purchase from multisite.)

[nb]

Are we using this somewhere?

[ockham]

Oops, rebase remnant. Good catch, thx. Removed in 1860f7e

[nb]

What’s the logic behind the new name flux-actions? Weren’t the previous ones flux actions, too?

[ockham]

What}S he logic behind the new name flux-actions? Weren’t the previous ones flux actions, too?

They were indeed :-) It's mostly so the new Redux actions (which share a lot of their implementation with the old Flux actions) can remain in actions.js, which makes the diff much more legible.

[aduth]

Continuing a previous discussion on helper methods for retrieving data from the stores.

Looks like you've chosen to include a few helper methods in the reducer modules. Any reason for doing this?

Something I've been experimenting with in #338 is to introduce the concept of a "selector", intended to map the state tree to something more usable (as used here, fetching status or lists). The term selector is used by both react-redux and the reselect library.

The mapStateToProps function takes a single argument of the entire Redux store’s state and returns an object to be passed as props. It is often called a selector.

In #338, I created an entirely separate file for these types of functions, separate from both actions.js and reducers.js, named selectors.js.

What are your thoughts on this? To be clear, this is not a request for changes to be made. I'm more interested in starting some dialogs around conventions we can try using with Redux.

[ockham]

I think it's a great idea to follow established Redux patterns, especially if they make a whole lot of sense, as do selectors -- I just haven't seen and/or internalized all those patterns. That said, this PR has been lying around for a while (even though it ha actually less impact than yours -- it's still wrapping Redux for usage with Flux), so I'd rather not stack added complexity on top as to not further delay merging it.

I'll open an issue though to move to the selector pattern later on. I'll also see to reviewing #338 soon.

[mcsf]

In #338, I created an entirely separate file for these types of functions, separate from both actions.js and reducers.js, named selectors.js.

Having played with selectors a little because of the Showcase (experimental branch), I think this should make a lot of sense. Will also be reviewing #338.

[mcsf]

I trust this to be good, by now. It shouldn't disrupt anything. We've had enough eyeballs and whatever may come up after merging can be fixed.

👍

[seear]

(which typically aren't that many)

We can probably lose the part of the comment in brackets without sacrificing any information.

[aduth]

site.slug is a computed attribute, which is not appropriate for the Redux state tree and will be removed in a future revision. See #2757 for tracking issue and 74052e7160bfc8d91f3d78fda4f2d1b4c919951b (#4055) for an example alternative.