New component: FieldValidation

[darrenjacoby]

Description

This PR creates a new <FieldValidation> component that can be used for required fields or fields that require custom tests for validation.

• Fields can be marked as required.
• Fields can have custom validation tests and responses.
• Editor "update" button is disabled if any field validation is failing on the post or page.

Screenshare with failing field validations;

demo-field-validation.mp4

Testing

Import <FieldValidation> and test with the following;

import { FieldValidation } from '@10up/block-components';

function BlockEdit(props) {
    const { attributes, setAttributes } = props;
    const { title } = attributes;

    return (
        <>
            <FieldValidation
                value={title}
                required={__('Title is a required field', '10up')}
                validate={[
                    [ (value) => /^[a-zA-Z\s]+$/.test(value), __('Title requires alphabetical characters', '10up') ],
                    [ (value) => /^.{10,}$/.test(value), __('Title requires 10 characters or more', '10up') ],
                ]}
            >
                    <RichText
                        tagName="p"
                        value={title}
                        onChange={(value) => setAttributes({ title: value })}
                    />
            </FieldValidation>
        </>
    )
}

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

• Added - Field Validation component

Credits

n/a

Checklist

• I agree to follow this project's Code of Conduct.
• I have updated the documentation accordingly.
• I have added tests to cover my change.
• All new and existing tests pass.

[fabiankaegy]

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 :)

[darrenjacoby]

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.

• .tenup--block-components__validation-error__field to style the field. For example, adding background-color: red; will made the field background red.

There are two other available custom classes;

• .tenup--block-components__validation-error__response to style the response container.
• .tenup--block-components__validation-error__response-rule to style each individual response rule (as there can be multiple rule failures).

[fabiankaegy]

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.

[darrenjacoby]

@fabiankaegy those are good points which all make sense to me! Let’s see how we can implement a nice default state 🙂

[darrenjacoby]

I've implemented some basic styling which matches some WordPress defaults. I'll await feedback from xavortm.

Responses;

• Default WordPress font stack
• Font size 13px
• Font weight 500
• WordPress color var(--wp--preset--color--vivid-red)

Field;

• Background color of var(--wp--preset--color--vivid-red) at 75% opacity.

Example on dark background;

Example on light background;

[xavortm]

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.