-
Notifications
You must be signed in to change notification settings - Fork 799
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
Calendly Block: Show an error when the embed url is not found #14814
Conversation
Caution: This PR has changes that must be merged to WordPress.com |
Thank you for the great PR description! When this PR is ready for review, please apply the Scheduled Jetpack release: April 7, 2020. |
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 works well for me. 🚢
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.
Followed all steps and they worked as described. 👍
extensions/blocks/calendly/edit.js
Outdated
@@ -65,6 +68,25 @@ export default function CalendlyEdit( props ) { | |||
</> | |||
); | |||
|
|||
useEffect( () => { | |||
if ( ! url || 'link' === style ) { |
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.
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 agree that it would be good to do this check for both styles of embed...
@pablinos The
Cases 1 and 2: we don't really need to check the URL, as it's implied that it has been already checked (more about it later). Case 3 is where this comes into play. Now, the resolve-redirect check runs always when you manually change the embed code (see the Now, by testing this again I could see two things that look off to me:
|
Copons, Your synced wpcom patch D39450-code has been updated. |
Ok, for some reasons I was wrong on this, or my dev tools skills aren't good enough. This happened because the This is not the case: as it turns out, pasting an URL directly creates the block with the What does this mean practically? Let's see case by case.
|
@scruffian have you tried with the latest changes? Specifically 08f921a should fix exactly that, as before we were also unintentionally resolving the example URL, and so slowing down the render of the preview embed. |
I've tried this a bit, as it seems like the most sensible solution, but I think the async gets in the way. |
extensions/blocks/calendly/edit.js
Outdated
return; | ||
} | ||
setResolveUrl( true ); | ||
apiFetch( { path: `/wpcom/v2/resolve-redirect/${ url }` } ).then( |
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.
Now that we rely on wpcom/v2/resolve-redirect
here, in the Pinterest block, and in the Eventbrite block, would it make sense / be possible to extract this into a shared function maybe? What do you think?
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 thinking!
I'll update this PR by adding an utility function, and then will take care of the other blocks separately to avoid bloating this.
10b5d6a
to
84d25ef
Compare
Copons, Your synced wpcom patch D39450-code has been updated. |
Copons, Your synced wpcom patch D39450-code has been updated. |
In 26fafa2 I've created a new I think the function documentation is clear enough, and there's also an example, but for the sake of clarity:
tl;dr this is how it works: const Block = () => {
const [ url, setUrl ] = useState( '' );
const [ isResolvingUrl, setIsResolvingUrl ] = useState( false );
const setUrlAttribute = () => {
testEmbedUrl( url, setIsResolvingUrl )
.then( () => setAttribute( { url } ) )
.catch( () => setAttribute( { url: undefined } ) );
};
if ( isResolvingUrl ) {
return <Spinner />;
}
return (
<form onSubmit={ setUrlAttribute }>
<TextControl value={ url } onChange={ setUrl } />
</form>
);
} |
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.
LGTM
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.
Tested and confirmed working. 👍
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 looks good to me. It should be good to merge!
Since it introduces a new file, you'll need to rebuild the matching wpcom diff manually I'm afraid.
r204401-wpcom |
* Initial changelog entry * Changelog: add #14904 * Changelog: add #14910 * Changelog: add #14913 * Changelog: add #14916 * Changelog: add #14922 * Changelog: add #14924 * Changelog: add #14925 * Changelog: add #14928 * Changelog: add #14840 * Changelog: add #14841 * Changelog: add #14842 * Changelog: add #14826 * Changelog: add #14835 * Changelog: add #14859 * Changelog: add #14884 * Changelog: add #14888 * Changelog: add #14817 * Changelog: add #14814 * Changelog: add #14819 * Changelog;: add #14797 * Changelog: add #14798 * Changelog: add #14802 * Changelog: add #13676 * Changelog: add #13744 * Changelog: add #13777 * Changelog: add #14446 * Changelog: add #14739 * Changelog: add #14770 * Changelog: add #14784 * Changelog: add #14897 * Changelog: add #14898 * Changelog: add #14968 * Changelog: add #14985 * Changelog: add #15044 * Changelog: add #15052 * Update to remove Podcast since it remains in Beta * Changelog: add #14803 * Changelog: add #15028 * Changelog: add #15065 * Changelog:add #14886 * Changelog: add #15118 * Changelog: add #14990 * Changelog: add #14528 * Changelog: add #15120 * Changelog: add #15126 * Changelog: add #15049 * Chanegelog: add #14852 * Changelog: add #15090 * Changelog: add #15138 * Changelog: add #15124 * Changelog:add #15055 * Changelog: add #15017 * Changelog: add #15109 * Changelog: add #15145 * Changelog:add #15096 * Changelog:add #15153 * Changelog: add #15133 * Changelog: add #14960 * Changelog: add #15127 * Changelog: add #15056 * Copy current changelog to changelog archive. * Clarify changelog description
Fixes #14805
Changes proposed in this Pull Request:
When inserting an URL, the block tests it through the
resolve-redirect
endpoint.On success, it sets the block's attributes and loads the embed.
On fail, it empties the URL attributes and shows an error notice.
To make this work with the automatic block transformation when pasting a Calendly URL, the
resolve-redirect
check runs on block mount, and whenever the URL attribute changes.This, unless the block style is
link
, as this implies that the URL passed the test already (and showing a "loading spinner" would look awkward.Is this a new feature or does it add/remove features to an existing part of Jetpack?
Testing instructions:
link
style.https://calendly.com/totally-incorrect-url
).Proposed changelog entry for your changes: