Introduce theme_supports with formats to REST API index
#6318
Conversation
|
@pento One implementation nuance to be aware of: if I create a Post with format |
There was a problem hiding this comment.
Left a couple of comments.
I'm not wild about the theme_supports name, but let's go with it for now, we can bikeshed over it later. If someone felt like building an endpoint similar to WPCOM's themes/mine, we could potentially move this info to there.
| // Ensure current format is always in the set. | ||
| // The current format may not be a supported format. | ||
| supportedFormats.push( format ); | ||
| supportedFormats = uniq( supportedFormats ); |
There was a problem hiding this comment.
Rather than the multi-step process for making supportedFormats unique, we can use the same pattern as we use in the PHP:
const supportedFormats = union( [ format ], get( themeSupports, 'formats', [] ) );| $result = $response->get_data(); | ||
| $this->assertTrue( isset( $result['theme_supports'] ) ); | ||
| $this->assertTrue( isset( $result['theme_supports']['formats'] ) ); | ||
| $this->assertTrue( in_array( 'standard', $result['theme_supports']['formats'] ) ); |
There was a problem hiding this comment.
It'd be good to test that post formats that aren't specified by the theme are not in the results, too.
There was a problem hiding this comment.
Given post formats can vary from theme to theme, and the theme active in the test suite is uncertain, can you suggest what you'd like me to test?
There was a problem hiding this comment.
On second thoughts, I don't know that it needs testing. I'd been looking at WPCOM's API, which tries to avoid loading the theme code if it can, so was considering how to test for that. But, that's not really an issue for Core.
core-data/resolvers.js
Outdated
| */ | ||
| export async function* getThemeSupports() { | ||
| const index = await apiRequest( { path: '/' } ); | ||
| yield receiveIndex( index, 'theme_supports' ); |
There was a problem hiding this comment.
Removed in 82bdfb5
core-data/selectors.js
Outdated
| * @return {Mixed?} Index data. | ||
| */ | ||
| export function getThemeSupports( state ) { | ||
| return state.indexData[ 'theme_supports' ]; |
There was a problem hiding this comment.
Why mixed square bracket notation? Is it because ESLint is throwing an error?
There's a question whether we should model our state shape how we want to use it in the client, i.e. camel-casing properties from the REST API. Less consistent with API properties, more consistent with JS standards. Not sure what the best option is here.
There was a problem hiding this comment.
Why mixed square bracket notation? Is it because ESLint is throwing an error?
Copy-pasta from above. I've changed in d64f40a
| return { | ||
| postFormat: getEditedPostAttribute( 'format' ), | ||
| supportedFormats: get( postType, [ 'formats' ], [] ), | ||
| supportedFormats: supportedFormats, |
There was a problem hiding this comment.
Minor: Could use property shorthand here:
supportedFormats,| export default combineReducers( { | ||
| terms, | ||
| media, | ||
| postTypes, | ||
| indexData, |
There was a problem hiding this comment.
Is Data suffix adding any value here? Would we want to call other reducers termsData, mediaData as well for consistency's sake?
There was a problem hiding this comment.
Is
Datasuffix adding any value here?
For me personally, it denotes that it's the data part of the index. index was too nebulous in my opinion (in comparison to terms, which more clearly communicates itself).
Would we want to call other reducers
termsData,mediaDataas well for consistency's sake?
I don't think so. However, if you're not a fan of indexData, I'm open to renaming it. Alternatively, we could only put themeSupports in the store, instead of the entire index.
* Add supported post formats to the post type REST API response * Filter the post formats we show in the PostFormat dropdown * Need to pass the slug to post_type_supports() * Standard post format is added in the end point response, no need to manually add it to the list * Introduce `theme_supports` with `formats` to REST API index (#6318) * Introduce `theme_supports` with `formats` to REST API index * Load supported formats from index into scope * Use `union` for a more concise logic declaration. * Remove unused second argument * Directly access the object variable * Use shorthand format * More consise variable definition * Remove `permalink_structure` definition, which has been removed * Focus state management on themeSupports data * Use lodash implementation of `includes()` for IE11 compat
Merges into #6301