Parsley Bundle Laravel Package

Product Decisions This Supports

• Unified Validation Ecosystem: Eliminates silos between frontend and backend validation by automatically syncing Symfony constraints (e.g., @Assert\Email, Length) to Parsley.js client-side rules. This reduces user confusion (e.g., "Why does the server reject my input when the form said it was valid?") and developer frustration from maintaining parallel validation logic.
• API-Driven Development: Enables zero-configuration validation for Swagger/OpenAPI-generated entities. If your API specs define validation rules (e.g., minLength: 8 for passwords), those rules can auto-propagate to client-side forms without manual mapping, accelerating microservices or headless CMS projects.
• Progressive Enhancement: Ensures forms remain functional without JavaScript while delivering richer feedback when JS is available. Critical for accessibility compliance (WCAG) and global markets where users may disable JS or use low-end devices.
• Third-Party Integration: Automatically validates data from external systems (e.g., payment gateways, CRM APIs) by leveraging their Symfony-annotated entities. Example: A Stripe payment form could use Stripe’s validation annotations to enforce card number rules on both client and server.
• Roadmap for Low-Code/No-Code: Reduces the need for custom frontend validation logic, aligning with trends toward composable architectures where business rules are defined in the backend and surfaced to the UI.
• Build vs. Buy: Justifies adoption over custom solutions for teams using Symfony/Laravel + Parsley.js, as it provides 90% of validation use cases out-of-the-box with minimal maintenance. The package’s Apache 2.0 license and Symfony ecosystem alignment reduce legal/integration risks.

When to Consider This Package

• Adopt if:
  • Your product relies on forms as a core interaction (e.g., SaaS platforms, e-commerce, admin panels) where validation UX directly impacts conversion rates or user retention.
  • You use Symfony Forms or Doctrine entities with validation annotations and want to eliminate manual client-side validation.
  • Your team prioritizes developer velocity and can tolerate the package’s alpha-stage limitations (e.g., unsupported validators like UniqueEntity).
  • You’re building multi-channel applications (web, mobile, admin) and need to sync validation rules across platforms without duplication.
  • You’re integrating with third-party APIs that provide Symfony-annotated entities (e.g., via Swagger Codegen) and want to reuse their validation logic.
  • Your audience includes users with JavaScript disabled (e.g., enterprise apps, government portals) or low-bandwidth environments (e.g., mobile markets).
• Look elsewhere if:
  • Your validation needs are trivial (e.g., only required fields) and can be handled with HTML5 attributes or a lighter library like Htmx + server-side validation.
  • You’re not using Symfony/Laravel or Parsley.js, and the integration effort outweighs benefits. Alternatives:
    • Laravel: Use laravel-validation + custom JavaScript (e.g., VeeValidate).
    • Non-Symfony: Use Vega or Validetta for client-side validation.
  • Your validation logic is highly dynamic (e.g., depends on real-time API responses) and can’t be statically mapped to Symfony constraints.
  • You need real-time validation (e.g., WebSocket updates) or visual feedback (e.g., animated tooltips) that Parsley.js doesn’t support.
  • Your team lacks Symfony/Parsley.js expertise, and the learning curve for customization (e.g., extending DirectiveInterface) is prohibitive.

How to Pitch It (Stakeholders)

For Executives: *"This package solves a hidden technical debt in our validation layer. Today, our frontend and backend teams maintain separate validation rules—leading to inconsistencies, bugs, and extra dev work. For example, if we add a MinLength constraint to a password field in Symfony, our frontend team must manually replicate it in JavaScript. This package automates that sync, so rules are defined once in Symfony and applied to both client and server.

Why it matters:

• Reduces support tickets: Users won’t see ‘valid’ forms rejected by the server.
• Speeds up development: No more copying/pasting validation logic between backend and frontend.
• Supports our API-first roadmap: If we generate entities from Swagger specs, their validation rules will auto-convert to client-side forms—cutting weeks of manual work.
• Future-proofs accessibility: Forms work without JavaScript while delivering richer feedback when JS is available.

Risk: It’s an alpha package with limited validators, but we can start with the 80% it covers (e.g., Email, Length, Required) and extend it later. The alternative—building this ourselves—would take 3–6 months and still miss edge cases.

Ask: Should we pilot this in our [User Onboarding Flow], where validation errors are a top source of drop-offs?"*

For Engineering: *"This bundle maps Symfony validation constraints to Parsley.js attributes, so you define rules once and they work everywhere. Here’s how it works:

Key Benefits

1. Auto-Sync Validation:

   • Add @Assert\Email to an entity or new Email() to a Symfony form → Parsley.js adds data-parsley-trigger="focusout" data-parsley-email="true" to the HTML.
   • Example: A Length(min=8) constraint becomes data-parsley-minlength="8".

2. Supports Our Stack:

   • Works with Symfony Forms, Doctrine entities, and Swagger-generated models.
   • Parsley.js is lightweight (~10KB) and widely used (e.g., by Bootstrap).

3. Flexible Overrides:

   • Client-only rules: Use the parsleys option in forms to add Parsley-specific validations (e.g., custom patterns).
   • Disable auto-magic: Remove specific constraints (e.g., new RemoveSymfonyConstraint(Regex::class)) if they don’t map cleanly to Parsley.
   • Custom directives: Extend DirectiveInterface to add new validators (e.g., for UniqueEntity).

4. Progressive Enhancement:

   • Forms degrade gracefully without JS, but gain real-time feedback when JS is available.

Tradeoffs

• Limited validators: Only supports ~10/50+ Parsley.js validators (e.g., no creditCard, phone). Workaround: Use parsleys for custom rules.
• Symfony-only: Requires Symfony Forms or Doctrine entities for full auto-magic. For Laravel, you’d need to bridge the gap (e.g., via symfony/validator).
• Alpha stage: Last release was 2018, but the core concept (constraint → attribute mapping) is stable.

Proposed Rollout

1. Pilot: Test in a non-critical form (e.g., [Settings Page]) with the supported validators (Email, Length, Required).
2. Extend: Add missing validators (e.g., Range, Pattern) via custom directives.
3. Document: Create a validation cheat sheet mapping Symfony constraints to Parsley.js attributes for the team.

Alternatives considered:

• Custom solution: Too risky (reinventing the wheel + maintenance).
• Parsley.js alone: Requires manual mapping of Symfony rules to JS.
• Other bundles: None offer the same Symfony integration.

Ask: Should we start with the pilot in [Module X] and measure the reduction in validation-related bugs?"*