Skip to content
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

Allow the <LinkFloatingToolbar /> component to be submitted with the 'enter' key when the <PlateEditor /> is contained within a <form></form> #3133

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

PaulSinghDev
Copy link

I encountered an issue whereby having the plate editor nested within a <form></form> lead to the <LinkFloatingToolbar /> triggering the form's submission method.

This meant that the link element was never added into the editor's context and that the user couldn't actually add one in via the insert menu.

Solution

The change is a very basic one and is nothing major. I simply added an onKeyDownCapture event listener to the wrapping div element. Within the callback I simply check whether key pressed is the Enter key and, if so, call the preventDefault() method exposed on the event.

I opened an issue for this the day I noticed it and thought it would probbably help to just run through the tests etc and then make the PR to make everyone's lidfe easier.

The issues which this closes is: #3130

The current floating link element exposes no button to trigger the insertion and relies on the user pressing enter. This is not a problem in itself but, if the user is placing the WYSIWYG editor within a form pressing enter will trigger the parent form's onSubmit method and the link will not be inserted. 

As such I have wrapped the floating insert in an blank form element which takes the form context away from the parent and means submission is handled by plate opposed to the wrapper.
In order to prevent hydration issues I have removed the nested form an instead opted for a keyDown listener which will preventDefault if the key is enter
Copy link

changeset-bot bot commented Apr 19, 2024

⚠️ No Changeset found

Latest commit: 4d4a9c5

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link

vercel bot commented Apr 19, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
plate ✅ Ready (Inspect) Visit Preview 💬 Add feedback Apr 23, 2024 7:26am

Comment on lines +76 to +80
onKeyDownCapture={(e) => {
if (e.key === "Enter" || e.keyCode === 13) {
e.preventDefault();
}
}}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we move this logic to the package, in FloatingLinkUrlInput?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zbeyens Sure I'll test it out today to make sure it works the same :)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zbeyens if we add it to the FloatingLinkUrlInput it will not capture the event that the user presses enter after entering text into the label input field and will invoke the errant behaviour of calling the parent form's submit method. As such I think the most pragmatic approach is either leave it where it is one of:

  • Move it to the next child down the tree (as this wraps both input fields)
  • Add it to both input fields (seems a bit excessive and harder to manage)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. Since we try hard to follow shadcn pattern, I think adding a new hook useFormInputProps in @udecode/plate-utils would be optimal, that should be used by any editor input (your second suggestion).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zbeyens no probs at all, I will try get something pulled together over this weekend :)

@zbeyens zbeyens marked this pull request as draft April 20, 2024 10:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants