Forms Laravel Package

Technical Evaluation

Architecture Fit

• Pros:

  • Laravel Compatibility: While primarily designed for Nette, nette/forms is standalone and can integrate with Laravel via composer (no framework lock-in). Its PSR-compliant structure (e.g., type hints, modern PHP) aligns with Laravel’s ecosystem.
  • Validation-Centric: Laravel’s built-in validation (e.g., Validator facade) is procedural and request-focused, whereas nette/forms offers a declarative, object-oriented approach with fine-grained control (e.g., per-field rules, custom validators, client-side sync via netteForms.js).
  • CSRF Protection: Built-in CSRF tokens (via Form::addProtection()) reduce Laravel’s manual csrf_token() boilerplate.
  • Frontend-Backend Sync: Client-side validation rules (e.g., data-nette-rules) can mirror server-side logic, reducing JavaScript validation duplication.
  • Modern PHP Support: PHP 8.1+ features (e.g., enums, attributes, strict types) ensure long-term compatibility with Laravel’s roadmap.

• Cons:

  • Templating Dependency: Relies on Latte for rendering (though standalone HTML rendering is possible via DefaultFormRenderer). Laravel’s Blade would require a custom renderer or middleware.
  • Event-Driven Model: Uses Nette’s event system (e.g., onValidate, onSuccess), which may feel unfamiliar to Laravel’s middleware/hook patterns.
  • No Native Eloquent Integration: Unlike Laravel’s FormRequest, nette/forms lacks built-in model binding (though Container::getValues($obj) supports hydration).

Integration Feasibility

• Laravel Stack Fit:
  • Validation: Replace Laravel’s Validator for complex forms (e.g., multi-step, dynamic fields) with nette/forms’ fluent API (e.g., $form->addText('email')->addRule(Email::class)).
  • Request Handling: Use nette/forms alongside Laravel’s Form Requests for hybrid validation (e.g., nette/forms for UI logic, Laravel for auth/authorization).
  • Frontend: Leverage netteForms.js for client-side validation without reinventing wheel (e.g., data-nette-rules="required|email").
• Migration Path:
  1. Pilot Phase: Replace 1–2 critical forms (e.g., login, checkout) to test integration.
  2. Renderer Adapter: Build a Blade-compatible renderer (extends DefaultFormRenderer) to replace Latte.
  3. Event Bridge: Map nette/forms events (e.g., onSuccess) to Laravel’s events or middleware.
  4. Incremental Adoption: Start with validation, then expand to rendering and CSRF.

Technical Risk

• High:
  • Templating Overhead: Latte dependency may require custom Blade macros or a renderer rewrite, adding 2–4 weeks of dev time.
  • Event System Learning Curve: Nette’s event model differs from Laravel’s service container hooks; team training may be needed.
  • CSRF Conflicts: Laravel’s built-in CSRF middleware may clash with nette/forms’ auto-generated tokens (mitigate via middleware ordering).
• Medium:
  • Performance: nette/forms is optimized for Nette’s DI, but Laravel’s service container may introduce minor overhead (benchmark critical paths).
  • Type Safety: PHP 8.1+ features (e.g., enums) require Laravel 9+; older versions may need polyfills.
• Low:
  • Validation Logic: Directly replaceable with minimal refactoring.
  • Frontend Integration: netteForms.js works with any modern JS framework (Vue, React, Alpine).

Key Questions

1. Templating Strategy:
   • Will the team build a Blade renderer or stick with Latte (via Nette integration)?
   • How will dynamic forms (e.g., AJAX-added fields) handle rendering?
2. Validation Workflow:
   • Should nette/forms replace Laravel’s Validator entirely, or complement it (e.g., for UI-specific rules)?
   • How will custom validators (e.g., Laravel’s Rule objects) integrate with nette/forms’ Validator class?
3. CSRF Handling:
   • Will Laravel’s CSRF middleware be disabled for nette/forms, or will a custom bridge be built?
4. Performance:
   • How will nette/forms scale in high-traffic forms (e.g., 10K+ submissions/day)? Are there caching strategies for validation rules?
5. Frontend Sync:
   • Will netteForms.js be used for all client-side validation, or will Laravel’s Livewire/Alpine handle some logic?
6. Testing:
   • How will PHPUnit tests for nette/forms integrate with Laravel’s Pest/Laravel TestCase?
7. Long-Term Maintenance:
   • Who will triage Nette-specific issues (e.g., Latte bugs) if the package diverges from Laravel’s ecosystem?

Integration Approach

Stack Fit

• Laravel Core:
  • Validation: Replace Validator facade for complex forms (e.g., multi-step, conditional fields).
  • Request Handling: Use nette/forms alongside FormRequest for UI-specific logic (e.g., client-side rules).
  • CSRF: Leverage nette/forms’ built-in tokens to reduce middleware bloat.
• Frontend:
  • JavaScript: Use netteForms.js for client-side validation (syncs with server-side rules).
  • Blade: Create a custom renderer to output nette/forms HTML in Blade templates.
• Database:
  • Model Binding: Use Container::getValues($obj) to hydrate Eloquent models (with caveats for nested relations).

Migration Path

Compatibility

• Laravel 9+: Required for PHP 8.1+ features (e.g., enums, attributes).
• Blade: No native support; must build a renderer adapter (extends DefaultFormRenderer).
• Livewire/Alpine: netteForms.js can coexist but may require event synchronization.
• Symfony Components: nette/forms is not Symfony-compatible; avoid mixing with symfony/validator.

Sequencing

1. Validation First:
   • Replace Laravel’s Validator for complex forms (e.g., surveys, admin panels).
   • Use nette/forms alongside FormRequest for auth/authorization logic.
2. Rendering Second:
   • Build a Blade renderer before migrating templating logic.
3. Frontend Last:
   • Integrate netteForms.js after server-side validation is stable.
4. CSRF:
   • Configure route-level middleware to avoid conflicts.

Operational Impact

Maintenance

• Pros:
  • Reduced Boilerplate: nette/forms’ fluent API cuts validation code by ~40%.
  • Centralized Rules: Client-server validation rules are synced via data-nette-rules, reducing duplication.
  • Nette Ecosystem: Access to **Nette