-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add VideoPress "benefit" card to plan removal screen #67181
Conversation
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser: Sections (~1374 bytes added 📈 [gzipped])
Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to. Legend What is parsed and gzip size?Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory. Generated by performance advisor bot at iscalypsofastyet.com. |
…aceholder, need to add logic to retrieve correct value
9cf81fa
to
00a3a0d
Compare
… route, so other uses of MediaQuery component will continue to work
getCurrentRoute( getState() )?.startsWith( '/media/' ) && | ||
! isEqual( | ||
omit( query, 'page_handle' ), | ||
omit( getNextPageQuery( getState(), siteId ), 'page_handle' ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@flootr Tagging you here since you originally make this fix for #44579
The query check was preventing the request from the QueryMedia
react component from completing anywhere except the Media Library in calypso because the "next page query" url always had number
and none of the passed in query filters (like mime_type
) as properties and the custom query that I provided to the component just had my mime_type
property. As a result it would always fall into this condition and not populate the media
state property, and my component would never get the updated data from the request.
It doesn't look like this change I'm making is causing the original issue to come back, unless I'm not testing correctly. Just hoping to get a second set of eyes on this incase you see an issue with the change.
Alternatively, it sounds like the original issue that was being fixed has something to do with old requests not being cancelled... I wonder if there is another way to solve for that that wouldn't require a special case to skip this check for the /media
route? Something like storing a "current query" instead and just comparing that with whatever is coming back in the result?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've actually replaced this change with a bug fix. Took a bit of investigating, but it looks like the <QueryMedia>
component wasn't setting the query
state, which was causing the isEqual
check in the above code to trigger when it shouldn't.
This has now been fixed directly in the <QueryMedia>
component!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Testing steps worked well and code LGTM.
Thanks! Before deploying I gave it another look and found out that one of the fixes I did was actually not necessary since the behaviour was caused by something completely different in Could you give the PR another review when you have time? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still works great, the new regression tests were fine.
This Pull Request is now available for translation here: https://translate.wordpress.com/deliverables/7526400 Thank you @jgcaruso for including a screenshot in the description! This is really helpful for our translators. |
Translation for this Pull Request has now been finished. |
* add check and benefit card for videopress -- video count is just a placeholder, need to add logic to retrieve correct value * change label to be less vague (and not misleading) * (maybe) fix for media request not being being in state * refactored videopress benefits card into separate file * use placeholder while data is loading * only allow early return for media library filter issue on the `media` route, so other uses of MediaQuery component will continue to work * cleanup comments * remove unused prop (copy-pasta) * handle nulls for current route * replace `/media` route special case with a bugfix
Proposed Changes
Jetpack VideoPress Product
Jetpack Complete (includes VideoPress)
Testing Instructions
/me/purchases/
/media/[some site]
, flip quickly between the filters (Images, Videos) and ensure the correct data is shown (from this issue fix(media): make sure we reset 'nextPageHandle' in case query changes #44579)/stats/month/[some site]
, ensure theVideos
section has data (this is an example of<QueryMedia>
being used without a query specified.Pre-merge Checklist
Related to #66076