-
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
Gutenberg: Update Related Posts block to pull real time related posts #27659
Conversation
That's a great PR description, thank you so much for your effort! Generated by 🚫 dangerJS |
I'm having trouble testing this. Could you upload a short video of it in action? |
Oh, sorry for that @MichaelArestad. It seems JN doesn't want to load with this branch - @oskosk do you have any idea what might be happening? In the meantime, here's a demo (added to the PR description too): https://cloudup.com/cCqjmXeOfLT The demo shows related posts for a draft post that has never been published, where you'll notice the following highlights:
|
3ddac75
to
ed892ae
Compare
@MichaelArestad note that it's easier now to test this PR - see the updated testing instructions. Note that some amount of posts should be created and synced (which could sometimes take some minutes) in order for you to test the functionality. |
Awesome! Tested! Thanks for making it easier to test. On my test, I added related posts blocks to each post I created as I created them. Once I had cranked out 3 or 4 with similar content, it was quite magical in how it updated. However, one thing I did notice is that those first already published posts did not update the related posts section as more posts were added. I even tried updating it a few times, removing the blocks and readding them. What I would expect is that the related posts are always changing as the site grows and more content is written. I expect this would happen without having to ever go back to the older posts to "update" the related posts content. Does that make sense? |
@MichaelArestad thanks for testing! Regarding the freshness of related posts - yeah, this is something I've noticed too, and it seems we will need to tackle it on an API level, so it's not related with the block work we're doing here. I've opened #27786 to keep track of it. @MichaelArestad do you have any other design feedback before we mark this "design approved"? |
No. It's awesome. #design-approved |
d98eaed
to
74f1080
Compare
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.
This is working quite nicely, thanks @tyxla!
Do you think we should re-fetch posts as the content changes? They seem to be fetched once when the block is loaded.
Not for this PR, but as we begin to consider targeting different environments, what do you think of adding fromApi
+ makeJsonSchemaParser
to these apiFetch
calls?
posts: response.posts, | ||
fetchingPosts: false, | ||
} ); | ||
} ); |
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.
What if there's a problem fetching? I think apiFetch
will reject, which we don't appear to handle.
Do we need to handle rejection? It looks like the placeholders will work and fetchingPosts
will be stuck to true
, but I'm wondering if these details are intentional.
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.
Good point, we're now handling fetching errors in 9f750ae
Thanks for the reviews, this is ready for another look. |
Ah, also to answer your questions @sirreal:
We already do that after any save / autosave - see https://github.com/Automattic/wp-calypso/pull/27659/files#diff-8957a4bfff8bf0279290b1093440645cR30
I've been thinking about it, but we're still far from that - we need a good, reliable, portable data system first. Maybe this use case could be a good start for experiments, but definitely in a separate PR, and probably not for the v1. |
That is when this related posts block is saved, right? I was wondering if it makes sense to update more frequently, perhaps on revision save. Once inserted, there's not much to do with this block, so I suspect save will happen infrequently. Consider a case where this block is part of a template and someone starts building out a post around it, the related posts will be outdated and not relevant as the post changes. Not a blocker, just something to consider. |
This seems to be completely wrong. It appears related posts are refetched on post (or revision) save just as I was suggesting. |
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.
e2e canaries had some failures, I've just re-run them.
Changes here are good, nice work 🙂
When tests are green, go ahead and 🚢 – please make sure we have some way to track translations for the placeholders.
Changes proposed in this Pull Request
moment
- use the API provided date, as it's already localized.Preview
https://cloudup.com/cCqjmXeOfLT
The demo shows related posts for a draft post that has never been published, where you'll notice the following highlights:
Testing instructions
Sandbox(not needed anymore, merged already).public-api.wordpress.com
Apply D19169-code to your WP.com sandbox(not needed anymore, merged already).Apply REST API: Add a related posts endpoint jetpack#10265 on your local Jetpack repo(not needed anymore, merged already).npm run sdk gutenberg client/gutenberg/extensions/presets/jetpack -- --output-dir=DIR_TO_JETPACK/jetpack/_inc/blocks
whereDIR_TO_JETPACK
is the directory that leads to your local Jetpack.Change(not needed anymore).JETPACK__SANDBOX_DOMAIN
to the domain of the WP.com test site that your WP.com sandbox is mapped to