Input Dialogs

AlertManagerInterface::input() creates a regular alert, then delegates the actual field configuration to an input type object.

Basic text input

  use Pentiminax\UX\SweetAlert\InputType\Text;

$alertManager->input(
    inputType: new Text(
        label: 'Display name',
        value: 'Tanguy',
        placeholder: 'Enter your public name'
    ),
    title: 'Update profile',
    text: 'This change is visible to other users.'
);

Select and radio inputs

Select and Radio accept an options array that becomes SweetAlert2 inputOptions.

  use Pentiminax\UX\SweetAlert\InputType\Select;

$alertManager->input(
    inputType: new Select(
        options: [
            'admin' => 'Admin',
            'editor' => 'Editor',
        ],
        label: 'Role',
        value: 'editor'
    ),
    title: 'Invite user'
);

Range, file, textarea, and HTML inputs

Class	Use case
Text	Simple text field with optional placeholder and attributes.
Textarea	Long-form text input.
Select	Select list powered by input options.
Radio	Choice list rendered as radio buttons.
Checkbox	Boolean or opt-in interactions.
File	File picker with optional accept attribute.
Range	Numeric slider with min, max, and step.
HtmlInputType	HTML-native inputs like email, password, number, date, or url.

Posting the result back to Symfony

input() exposes a callback argument. When it is non-empty, the created alert stores a callback URL and the frontend controller performs a POST request with the SweetAlert result.

  use Pentiminax\UX\SweetAlert\InputType\Text;
use Symfony\Component\Routing\Generator\UrlGeneratorInterface;

$alertManager->input(
    inputType: new Text(label: 'Project name'),
    title: 'Create project',
    callback: $this->generateUrl('app_project_modal_result', referenceType: UrlGeneratorInterface::ABSOLUTE_URL)
);

The request body matches the Result shape: isConfirmed, isDenied, isDismissed, and value.

Validation and extra attributes

You can keep customizing the returned Alert object after input():

  $alertManager
    ->input(
        inputType: new Text(
            label: 'Display name',
            inputAttributes: ['maxlength' => '40']
        ),
        title: 'Update profile'
    )
    ->validationMessage('A display name is required.')
    ->withCancelButton();

Input Types for constructor-level details.
Result & Callbacks for the backend callback flow.

Server-side validation with `preConfirmUrl`

preConfirmUrl() POSTs the confirmed value as JSON ({"value": ...}) to your endpoint while the modal stays open with a loader.

  $alertManager->addAlert(
    Alert::new(title: 'Pick a username')
        ->input('text')
        ->withCancelButton()
        ->preConfirmUrl('/username/check', 'Network error')
);

  #[Route('/username/check', methods: ['POST'])]
public function check(Request $request): JsonResponse
{
    $name = $request->getPayload()->get('value');

    return taken($name)
        ? new JsonResponse(['message' => 'Already taken'], 422)
        : new JsonResponse(['username' => $name]);
}

A non-2xx response keeps the modal open and shows message or detail (or the error message passed as the second argument, default Request failed).
A 2xx JSON response closes the modal and becomes result.value, which callbackUrl() also receives. A 2xx response that is not JSON keeps the user’s input as result.value, and a JSON false body is delivered as null (SweetAlert2 treats false as a refusal).
Only the confirm button triggers the request; outside click and Esc are blocked while it runs.
The endpoint must accept POST only and enforce its own access control: there is no CSRF token.

Validating with Symfony Constraints

With symfony/validator installed (composer require symfony/validator), PreConfirmResponse::fromViolations() turns a violation list into the response the modal expects. Any constraint works, including ones that need the database such as UniqueEntity when you validate an object.

  use Pentiminax\UX\SweetAlert\Http\PreConfirmResponse;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Validator\Constraints as Assert;
use Symfony\Component\Validator\Validator\ValidatorInterface;

#[Route('/username/check', methods: ['POST'])]
public function check(Request $request, ValidatorInterface $validator): Response
{
    $name = $request->getPayload()->get('value');

    $violations = $validator->validate($name, [
        new Assert\NotBlank(),
        new Assert\Length(min: 3, max: 20),
    ]);

    return PreConfirmResponse::fromViolations($violations, ['username' => $name]);
}

With violations: 422 {"message": "..."} holding the first violation’s message, so the modal stays open and shows it.
Without violations: 200 with the second argument as JSON (it becomes result.value; false arrives as null), or an empty 204 when it is omitted or null, which keeps the user’s input as result.value.

Constraints are only checked on the server: they are not translated to HTML input attributes. For instant client-side checks, set them yourself with inputAttributes() (e.g. required, minlength) and validationMessage().