Data Module: Refactor media fetching to use the core data module #5707

youknowriad · 2018-03-20T09:19:11Z

Follow up to #5219

The idea is to leverage the resolver API to replace the usage of the withAPIData HoC by the core data module. In this PR, I'm adding support to media fetching to the core-data module.

Testing instructions

Use the Image/Gallery blocks
Set, remove, update the featured image
It should work like master.

youknowriad · 2018-03-20T09:20:46Z

core-data/test/resolvers.js

+		} );
+	} );
+
+	it( 'yields with requested media', async () => {


I really like these tests. Nice work setting up the pattern @aduth

It also shows that we could push it further by avoiding the mocks entirely (using call effect) but granted that it's not that important at the moment.

youknowriad · 2018-03-20T09:22:03Z

core-data/resolvers.js

+ * @param {Object} state State tree
+ * @param {number} id    Media id
+ */
+export async function* getMedia( state, id ) {


I was wondering if passing the state to the resolvers is a good idea? Maybe it's useless, since we can still call select from inside the resolver if needed. Kept it as is for now, but let's see how this goes.

Indeed, I'm not too sure how much we want to promote the use of select, particularly in a context where we know we could call selectors via direct import and pass the state. Another reason was merely to align the signatures between selectors and resolvers (since their names already match).

See also: #5219 (comment)

youknowriad · 2018-03-20T09:24:32Z

core-data/resolvers.js

+ */
+export async function* getMedia( state, id ) {
+	const media = await apiRequest( { path: `/wp/v2/media/${ id }` } );
+	yield receiveMedia( media );


I'm not tracking any "is requesting" state at the moment because it's not really needed for our current use-cases. But I was wondering if we should have a separate requests state tree to keep track in a generic way of these states regardless of the request data type, query, ...

Same here, I guess we'll see with use-cases while adding other resolvers.

But I was wondering if we should have a separate requests state tree to keep track in a generic way of these states regardless of the request data type, query, ...

The original implementation in ffb0760 had a standalone requested state, which was meant to be generic and may still be an option to explore. The idea of not having a dedicated state works particularly well when we adopt a pattern of a null value meaning that it's known to exist, but not yet having received the entities. Though this works only with collections. With singular entities, a null value may instead mean having received an empty entity (404?). I agree we'll have to see how it plays out.

Related: #5219 (comment)

aduth · 2018-03-20T18:16:27Z

blocks/library/gallery/gallery-image.js

@@ -75,10 +76,10 @@ class GalleryImage extends Component {
 	}

 	componentWillReceiveProps( { isSelected, image } ) {
-		if ( image && image.data && ! this.props.url ) {
+		if ( image && ! this.props.url ) {


When will image be falsey?

Before the API loads the image?

Oh I didn't see the object fallback

Not related to this pull request, but why do we access this.props.url here? Should this not be from the nextProps argument?

aduth · 2018-03-20T18:18:50Z

blocks/library/gallery/gallery-image.js

@@ -147,6 +148,6 @@ class GalleryImage extends Component {
 	}
 }

-export default withAPIData( ( { id } ) => ( {
-	image: id ? `/wp/v2/media/${ id }` : {},
+export default withSelect( ( select, { id } ) => ( {


Minor: This works well for an in-place replacement, but in my own experience I want to start going out of my way to be more verbose with how we use withSelect, to set a good precedent especially when scaling a component to select many things from the same store (example), and to avoid both (a) in-place ownProps destructuring (destructuring obscures what is being destructured when used in arguments) and (b) the arrow function implicit return of objects (difficult to discern between implicit return and a function body).

This is how I would write:

export default withSelect( ( select, ownProps ) => { const { getMedia } = select( 'core' ); const { id } = ownProps; return { image: id ? getMedia( id ) : null, }; } )( GalleryImage );

Or:

export default withSelect( ( select, ownProps ) => { const { getMedia } = select( 'core' ); const { id } = ownProps; if ( ! id ) { return; } return { image: getMedia( id ), }; } )( GalleryImage );

aduth · 2018-03-20T18:20:48Z

blocks/library/image/block.js

@@ -136,7 +136,7 @@ class ImageBlock extends Component {
 	}

 	getAvailableSizes() {
-		return get( this.props.image, [ 'data', 'media_details', 'sizes' ], {} );
+		return get( this.props.image, [ 'media_details', 'sizes' ], {} );


Observing that we're still pretty bound to the REST API structure of an entity with the new core-data module. This has its upsides (easy state insertion, consistency), but also doesn't help decouple from the REST API.

Agreed, I was wondering if we should introduce "models" somehow

aduth · 2018-03-20T18:21:30Z

blocks/library/image/block.js

@@ -297,14 +297,14 @@ export default compose( [
 	withContext( 'editor' )( ( settings ) => {
 		return { settings };
 	} ),
-	withAPIData( ( props ) => {
+	withSelect( ( select, props ) => {
 		const { id } = props.attributes;
 		if ( ! id ) {
 			return {};


Minor: With #5421, we don't need to return an object.

aduth · 2018-03-20T18:24:16Z

editor/components/post-featured-image/index.js

 									</ResponsiveWrapper>
 								}
-								{ media && media.isLoading && <Spinner /> }
+								{ ! media && <Spinner /> }


What if a media request returns 404 ? This is a concern with treating "empty" as equivalent to "request in progress".

I think I'm fine with this right now, we can revisit once/if we introduce request state

aduth · 2018-03-20T18:24:50Z

core-data/test/selectors.js

+		let state = deepFreeze( {
+			media: {},
+		} );
+		expect( getMedia( state, 1 ) ).toBe( undefined );


Minor: Seems like a separate test case to me (it should return undefined for unknown media)

aduth · 2018-03-20T18:25:27Z

core-data/reducer.js

@@ -37,6 +42,19 @@ export function terms( state = {}, action ) {
 	return state;
 }

+export function media( state = {}, action ) {


DocBlock 😄

aduth · 2018-03-21T18:54:21Z

blocks/library/gallery/gallery-image.js

@@ -75,10 +76,10 @@ class GalleryImage extends Component {
 	}

 	componentWillReceiveProps( { isSelected, image } ) {
-		if ( image && image.data && ! this.props.url ) {
+		if ( image && ! this.props.url ) {


Not related to this pull request, but why do we access this.props.url here? Should this not be from the nextProps argument?

aduth · 2018-03-21T19:01:34Z

editor/components/post-featured-image/index.js

+	const { getMedia } = select( 'core' );
+
+	return {
+		image: featuredImageId ? getMedia( featuredImageId ) : null,


You've changed the prop name from media to image in the mapping function, and it's resulting in the featured image never being displayed (the underlying component expects a media prop).

Damn copy/paste

@aduth

Fixed, thanks @aduth

Data Module: Refactor media fetching to use the core data module

4a1e75f

youknowriad self-assigned this Mar 20, 2018

youknowriad requested a review from aduth March 20, 2018 09:19

youknowriad commented Mar 20, 2018

View reviewed changes

aduth reviewed Mar 20, 2018

View reviewed changes

youknowriad added 3 commits March 21, 2018 10:51

Use a unique pattern in withSelect HoC

740eaa8

Clarify media selector unit tests

40ce288

Adding media reducer doc block

e8cbece

aduth previously requested changes Mar 21, 2018

View reviewed changes

Fix featured image regressin

2388e13

youknowriad merged commit 89205a9 into master Mar 22, 2018

youknowriad deleted the update/media-fetching branch March 22, 2018 08:02

youknowriad mentioned this pull request May 16, 2018

Fix a race condition in withAPIData() #6303

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Data Module: Refactor media fetching to use the core data module #5707

Data Module: Refactor media fetching to use the core data module #5707

youknowriad commented Mar 20, 2018

youknowriad Mar 20, 2018

youknowriad Mar 20, 2018

aduth Mar 20, 2018

youknowriad Mar 20, 2018

aduth Mar 20, 2018

aduth Mar 20, 2018

youknowriad Mar 21, 2018

youknowriad Mar 21, 2018

aduth Mar 21, 2018

aduth Mar 20, 2018

aduth Mar 20, 2018

youknowriad Mar 20, 2018

aduth Mar 20, 2018

aduth Mar 20, 2018

youknowriad Mar 21, 2018

aduth Mar 20, 2018

aduth Mar 20, 2018

aduth Mar 21, 2018

aduth Mar 21, 2018

youknowriad Mar 21, 2018

Data Module: Refactor media fetching to use the core data module #5707

Data Module: Refactor media fetching to use the core data module #5707

Conversation

youknowriad commented Mar 20, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment