Validation Renderer has no way to provide success styling

I’m submitting a feature request

Current behavior: I am able to create a custom validation renderer that detects when an element has become invalid. With this we can apply error styling and then we can detect when that element is transitioning from an invalid state, back to a valid state and I can then apply success styling. As seen here:

    render(instruction: RenderInstruction) {
       for (let {error, elements} of instruction.unrender) {
            for (let element of elements) {
                this.remove(element, error);
            }
        }

        for (let {error, elements} of instruction.render) {
            for (let element of elements) {
                this.add(element, error);
            }
        }
    }

    private add(element: Element, error: ValidationError) {
        // Add error styling
    }

    private remove(element: Element, error: ValidationError) {
        // Remove error styling
        // Add success styling
    }

But how would I apply success styling when the element was never invalid? I can see in my custom renderer that the render function is called, but the RenderInstruction of kind “validate” contains no elements for me to add styling to. On a new form, on a valid field, the RenderInstruction provided to the render method on my custom renderer looks like this:

kind: "validate"
render: Array[0]
unrender:Array[0]

As you can see, I have no way of knowing which elements were validated successfully therefore cannot apply styling.

Perhaps adding an unrender() event on the ValidationRenderer or a new kind on RenderInstruction could work?

[EisenbergEffect]

I would support the change. It’s a more flexible design and similar to what I’ve seen done in other libraries.

[jsobell]

OK, quick brain dump because it’s 11:30pm here and my synapses are shutting down…

I have no issue making the change you suggest, as it should work around most of these problems, and this is one aspect I was wurbling on about when I mentioned needing more information in the renderer, but I think is also related to the discussion about having custom rules associated or ‘bound’ to arbitrary visual elements. This is one of those tricky crossovers between object and UI validation. Because we can have object level rules, but the user wants the results reflected on-screen, what binds the object level rule to anything in the DOM? As far as validation feedback is concerned we don’t care if the rule is linked to an input field or a span, as long as we can display the error. If we implement the solution where the user is handed a list of both property validation result and the related DOM entity, we really need to provide the DOM elements that they consider related even if they were not validation-bound inputs.

A simple example might be that firstname+lastname are less than 50 characters. We add this as a model rule, but it’s not linked to one input field, so the user wants the error displayed below those two fields. When the renderer is called, it has no visual element associated, so how does the user associate this with a point in the DOM to display the error or the green ‘OK’ result discussed by the OP?

My original suggestion was that all Model level rules have a fake property or ‘ID’, so we could have a custom attribute anywhere on the form to flag the location (or locations) to be passed to the renderer, and in the above example it would probably be on a div enclosing first and last name input fields.

Essentially, once we start raising events intended for UI feedback (even though they are really only property feedback) we need to allow this to happen, as moving the error-centric to be rule-centric needs to be able to provide enough details to allow ui-centric coding when required.

Treacherous partly gets around this by always having the entire collection of passed and failed rules available (as your solution would do), and you can request the message and status of any property by name, even if that property is an object level pseudo-property/ID/tag.