-
Notifications
You must be signed in to change notification settings - Fork 40
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
New component: FieldValidation #238
Conversation
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 really cool and works like a charm! Thank you for your contribution!
The only thing I would like to workshop a little bit more is how we style the inline errors. Using floatingUI is great and solves most of our issues already. However I think we should maybe think about making the entire background a solid color so we can ensure legibility.
@Sidsector9 implemented a similar thing in #235 which we may be able to use as an inspiration.
Maybe @xavortm also has an idea of what this could look like :)
Hey @fabiankaegy , Thanks for taking a look! There's probably a good case to be made for leaving styling options to developers on each project to account for things like dark-mode/brand colors, etc. But definitely open to design suggestions for defaults. In the interim, pushed an update which implements an error class on the field itself.
There are two other available custom classes;
|
I love the addition of the classes. However, I kind of disagree that it should be up to the developer to determine how the invalid state should look. The validation issue is not part of the content and counts as part of the editor frame. Having a standardized way to showcase invalid content which then can be overwritten, but in most cases doesn't need to be overwritten, is what I would prefer here. The goal of the block components is to remove as much complexity from the developers on individual projects. And having to re-invent how to style the invalid state of a component in the editor doesn't add a lot of value to a client in my perspective. And it creates the risk that when not styled correctly we create very unclear confusing experiences where a user doesn't understand why they are not able to save the post. That isn't to say that I don't want anyone to be able to overwrite the default styling. But I think there should be decent opinionated default styling that makes it look as though it were a core API and part of the native editor experience. So using the editors font, color scheme etc. |
@fabiankaegy those are good points which all make sense to me! Let’s see how we can implement a nice default state 🙂 |
I've implemented some basic styling which matches some WordPress defaults. I'll await feedback from xavortm. Responses;
Field;
|
Hi! Joining with some design proposals about the validation UI/UX: Please see here: https://www.figma.com/file/YtfzsSMXZJb2N2pfnuuAI3/Blocks-validation?type=design&node-id=0%3A1&mode=design&t=HeaSOLhTcoyL21Rc-1 I have listed the steps and states, including singular and combinations blocks (like core/blocks). For visual guide/direction, please see the blue section marked as "Ready for dev" on the right. Here is also a screenshot from it: It uses a component from Gutenberg but also adds a slight shadow to work better on white backgrounds. The Figma docs point to https://developer.wordpress.org/block-editor/how-to-guides/notices/ for the component reference. |
Description
This PR creates a new
<FieldValidation>
component that can be used for required fields or fields that require custom tests for validation.Screenshare with failing field validations;
demo-field-validation.mp4
Testing
Import
<FieldValidation>
and test with the following;Known issue:
<RichTextCharacterLimit>
also uses floating-ui and seems to impact the ref used by<FieldValidation>
when nested, impacting the position of validation responses. Solution requires further investigation.Changelog
Credits
n/a
Checklist