{{--
    Client-side validation for one form, generated from a FormRequest.

        <x-form.jsvalidation :request="\App\Http\Requests\ProjectRequest::class"
                             selector="#nrems_project_form" />

    Drop it anywhere inside the view that renders the form — it emits nothing
    where it sits, only three @push('scripts') blocks:

        1. the jsvalidation library (jQuery Validation + Laravel's rule
           translations), guarded by @once so a page with several forms still
           loads it exactly once;
        2. the generated <script> that binds those rules to `selector`;
        3. a two-line <script> handing that same selector to
           NREMS.Forms.bindValidationErrorPlacement (CR-5 §15.3.3), which
           moves every client-side message to where the server puts its own:
           after the control, at the end of the .form-group.

    Block 3 is here, in the component, rather than in nrems-custom.js's own
    init, and that is the deliberate half of the design. The placement
    *function* is shared and lives in nrems-custom.js; the *binding* has to
    name a form, and this component is the only thing in the application that
    knows which forms have a validator attached — it is what attached them.
    Putting it here means every jsvalidation form is covered by construction,
    and a page that never renders this component never has its validators
    reached into. A scan for `[data-…]` marker attributes in nrems-custom.js
    would have needed the views to opt in one by one, which is the failure
    mode the twin rule already fights.

    It is pushed AFTER block 2 and both bind on jQuery's ready queue, so the
    generated `.validate()` call has always run by the time block 3 looks for
    its validator. nrems-custom.js is `defer`red in the layout, which resolves
    strictly before DOMContentLoaded, so NREMS is defined by then too.

    Props:
        request   FormRequest class name (or an instance). Its rules() output
                  is what gets translated into Javascript.
        selector  jQuery selector for the form, e.g. "#nrems_project_form".
                  Always pass one: the config default is "form", which would
                  bind this rule set to every form on the page.
        except    Rule keys to leave out of the *client* set — file slots, and
                  the wildcard rules of a repeater whose rows do not exist when
                  the page renders (spec §8). The server still validates every
                  one of them; a key listed here simply gets no client-side
                  message. The list belongs with the rules, not with the view:
                  StoreProjectRequest::clientRuleExclusions() is the pattern.
                  An entry is an exact key, or a `units.*` form that drops
                  every key under `units` — form_rules_except() has the two
                  cases and the reason there is no third.

    Two code paths, and the difference is only how the rule set is obtained:
    with no exclusions the package resolves the FormRequest itself
    (JsValidator::formRequest), and with exclusions we build the same instance
    through form_request_instance(), drop the listed keys and hand the rest to
    JsValidator::make(). For the requests in this application the two are
    equivalent — JsValidatorFactory::oldFormRequestValidator() is make() with
    the request's rules, messages and attributes — so the same rules render the
    same config either way, and the default path stays untouched for the forms
    that never needed an exclusion. (Not a claim about the package in general:
    a request implementing proengsoft's own Remote\FormRequest would take a
    different branch inside formRequest(), and none here does.)

    Requirements the layout must meet — both app.blade.php and guest.blade.php
    already do:
        * jQuery loaded before @stack('scripts') (it is inside Metronic's
          plugins.bundle.js);
        * a @stack('scripts') to push into.

    The rules are a *convenience*, never a control: everything here runs in the
    user's browser and can be switched off from the console. The server-side
    FormRequest is what actually protects the endpoint.

    {!! !!} is the documented jsvalidation usage — the object renders a
    <script> element, so escaping it would print the source instead of running
    it. Nothing user-supplied reaches it: the output is built from rules() and
    from validation messages, which jsvalidation itself html-escapes
    (config('jsvalidation.escape')).
--}}
@props([
    'request',
    'selector',
    'except' => [],
])

@php
    $excluded = array_values(array_map(strval(...), (array) $except));

    if ($excluded === []) {
        $validator = JsValidator::formRequest($request, $selector);
    } else {
        $formRequest = form_request_instance($request);

        $validator = JsValidator::make(
            form_rules_except($formRequest->rules(), $excluded),
            $formRequest->messages(),
            $formRequest->attributes(),
            $selector,
        );
    }
@endphp

@once
    @push('scripts')
        <script src="{{ asset('vendor/jsvalidation/js/jsvalidation.min.js') }}"></script>
    @endpush
@endonce

@push('scripts')
    {!! $validator !!}
@endpush

@push('scripts')
    <script>
        jQuery(function () {
            // Guarded rather than assumed: a page that lost nrems-custom.js
            // should validate with the package's own placement, not throw on
            // every load.
            if (window.NREMS && window.NREMS.Forms) {
                window.NREMS.Forms.bindValidationErrorPlacement(@json($selector));
            }
        });
    </script>
@endpush