-
Notifications
You must be signed in to change notification settings - Fork 4.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
Experiment: use the Interactivity API to do client-side form submissions #49305
Experiment: use the Interactivity API to do client-side form submissions #49305
Conversation
Size Change: +1.02 kB (0%) Total Size: 1.35 MB
ℹ️ View Unchanged
|
Co-authored-by: Luis Herranz <luisherranz@users.noreply.github.com>
Co-authored with @michalczaplinski
Michal and I have finished the basic functionality, and it seems to work pretty well so far. I made a video to explain how it works: https://www.loom.com/share/a8ee7ae872f3485d89c8f6c49988e693 Oh, after recording the video, I realized this should also use the new |
In AMP, all POST form submissions are required to be done via fetch. There may be some prior art which is useful here in terms of loading states, success/failure messages, and so on: https://amp.dev/documentation/components/amp-form |
const formData = new FormData( event.target ); | ||
|
||
const res = await fetch( | ||
'http://localhost:8888/wp-comments-post.php', |
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 will allow the action to not be hard-coded:
'http://localhost:8888/wp-comments-post.php', | |
event.target.action, |
state.core.commentsFormError = | ||
dom.querySelector( 'p' ).innerHTML; | ||
} else { | ||
navigate( res.url, { |
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.
Normally when leaving a comment, the submission will take you to the permalink for the comment. For example, https://localhost:8888/?p=1#comment-2
. But here it seems navigate
doesn't include the URL fragment. I think this should be retained as it is normal WP behavior and it facilitates linking/bookmarking. With that URL fragment in place, it would also be a nice touch if there was a yellow fade highlight applied to the comment via the .comment:target
CSS selector to make it abundantly clear where there newly-added comment is showing up.
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.
But here it seems navigate doesn't include the URL fragment. I think this should be retained as it is normal WP behavior and it facilitates linking/bookmarking.
The client router doesn't support hashes yet, but I've opened an issue to track it. Thanks 🙂
it would also be a nice touch if there was a yellow fade highlight applied to the comment via the .comment:target CSS selector to make it abundantly clear where there newly-added comment is showing up
That would be a very nice touch indeed.
'text/html' | ||
); | ||
state.core.commentsFormError = | ||
dom.querySelector( 'p' ).innerHTML; |
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 might be a bit more robust:
dom.querySelector( 'p' ).innerHTML; | |
dom.querySelector( '.wp-die-message' ).innerHTML; |
Not only would it preserve the paragraph in the response (instead of rendering the text in a bare div
), but it would also account for there possibly being additional paragraphs or other elements rendered on the comment error screen.
This is awesome. Thank you for sharing the video presenting how it works. I was surprised to learn how advanced the implementation is with so little custom code. By the way, I created a new label in the repository: |
@@ -45,11 +45,17 @@ function render_block_core_post_comments_form( $attributes, $content, $block ) { | |||
// to the block is carried along when the comment form is moved to the location | |||
// of the 'Reply' link that the user clicked by Core's `comment-reply.js` script. | |||
$form = str_replace( 'class="comment-respond"', $wrapper_attributes, $form ); | |||
$form = str_replace( '</form>', '<div style="color: red;" data-wp-text="state.core.commentsFormError"></div></form>', $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.
FWIW, there's a comment_form_after
action that can be used to render stuff here. (Though I'm not sure it's worth using it here as it'd require adding the action before the comment_form()
call and removing it after.)
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.
On second thought -- if we're not married to this exact location (i.e. right before the </form>
, which means after the 'Submit' button), we might also use one of the (many) options to the comment_form
function. There is e.g. comment_notes_after
which is rendered after the textarea
(before the 'Submit' button), and which defaults to the empty string.
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 brings to mind something important: it could be that when the user submits the form, the button could be positioned at the bottom of the viewport. In such a case, the injected error message container may not be visible when it gets populated. The user could then be very frustrated and rage tap the submit button confounded as to why nothing is happening. Perhaps the error message should get displayed as a snackbar with position:fixed
or else scrolled into view if not visible.
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.
The snackbar seems like a great idea. The message would also have to get announced when using assistive technologies. In both cases when it’s successful, or it fails.
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 like the snackbar idea! We can try it to see how it feels and to see how easy it would be to create one with the Interactivity API 🙂
Superseded by #53737. |
Co-authored with @DAreRodz and @michalczaplinski.
What?
Experiment using the Interactivity API to do client-side form submissions.
The Interactivity API is an experimental API to add frontend interactivity to blocks. More info here
Why?
To see what API would be needed for
navigate
(or a new API for this use case).How?
data-wp-on.submit
to the form using the HTML Tag Processor.fetch
.Next steps
navigate
API to accept an HTML string. Maybe use a different API.Reply
buttons. Maybe using client-sidewp-slot
andwp-fill
.Testing Instructions
It's not working yet.