Themes: Add theme-details Redux subtree and data fetcher component

[ockham]

Use the REST API v1.1's /theme endpoint for now.

Relevant to #2875

[mcsf]

Why remove the binding? Doesn't this break fetching in refresh?

[ockham]

https://github.com/rackt/react-redux/blob/master/docs/api.md#connectmapstatetoprops-mapdispatchtoprops-mergeprops-options:

• [mapDispatchToProps(dispatch, [ownProps]): dispatchProps] (Object or Function): If an object is passed, each function inside it will be assumed to be a Redux action creator. An object with the same function names, but bound to a Redux store, will be merged into the component’s props.

So bindActionCreators is apparently redundant here and can be safely dropped, since connect() does the binding for us.

[mcsf]

Aha! I didn't remember that at all. :)

[seear]

A confusing thing at the moment is that this new theme-details section of state tree has less information than the existing themes section. This feels like some knotty technical debt, but I think we have to live with it for now.

[seear]

It is very tempting to introduce a new Elastic Search endpoint now to populate theme-details, because a new endpoint would be faster and have no caching issues. However, the new endpoint is a known, risk-free proposition, so let's use 1.1 for now and forge ahead.

[ockham]

A confusing thing at the moment is that this new theme-details section of state tree has less information than the existing themes section. This feels like some knotty technical debt, but I think we have to live with it for now.

I went with the basic stuff that's required for #2875, tough it's obviously easy to add more fields as returned by the endpoint. I was just thinking adding them as we move forward made more sense than adding too many now and pruning back later. That said, we can add stuff like screenshot, description, or description_long already...

[seear]

I went with the basic stuff that's required for #2875

Yeah, that makes total sense. I'm more thinking of how do we answer the question, "what is the difference between themes and theme-details?"

[ockham]

themes-details is really meant to return information for a given theme (and that can be quite a lot of information to go over the network, see description_long), while themes fetches all themes for a given site, but with only the level of detail that is needed themes-listing pages.

I agree however that the separation of concerns could be clearer, but to me that's more about refactoring themes and themes-list subtrees.

[seear]

but to me that's more about refactoring themes and themes-list subtrees.

yeah, totally agree

[seear]

what is the ! this.props.name part for here?

[seear]

The amount of boilerplate required to add a few fields to the store is mildly alarming. Regardless, this is looking good to go 👍

[mcsf]

Looking at this again: would it have been advantageous to reuse the themes reducer (and actions?) and have the new getThemeDetails return a subset of a theme's data? Complemented with a special hasThemeDetails that would look for specific fields, the data fetcher component would know when to trigger a fetch.

That said, I don't mind merging this right now and leaving all that to a latter and larger tree consolidation effort.