Request To Form Bundle Laravel Package

Product Decisions This Supports

• Reducing Boilerplate in Form Handling: Eliminates repetitive code for form creation, submission, and validation in controllers, aligning with Symfony’s DTO mapping (#[MapRequestPayload]) but for forms. This supports a cleaner, more maintainable API layer.
• Accelerating API Development: Enables rapid prototyping of CRUD endpoints (e.g., REST/GraphQL) by auto-binding request data to form-validated entities, reducing development time by ~30–50% for standard use cases.
• Consistent Validation Logic: Centralizes validation rules (e.g., Symfony’s validation_groups) in form types while ensuring they’re applied uniformly across all endpoints, improving data integrity.
• Hybrid Workflows: Supports use cases like partial updates (PATCH) or query filtering (GET) where request data must be merged with existing entities or transformed into structured inputs (e.g., Elasticsearch queries).
• Build vs. Buy: Favors buying this lightweight package over building custom middleware/resolvers for form handling, given its alignment with Symfony’s ecosystem and minimal maintenance overhead.
• Roadmap Priorities:
  • Phase 1: Adopt for new API endpoints to reduce technical debt.
  • Phase 2: Retrofit existing endpoints to leverage form validation (e.g., migrating from manual $request->request->all() to validated forms).
  • Phase 3: Extend to non-API contexts (e.g., admin panels) where form submission is manual.

When to Consider This Package

• Adopt When:

  • Your Symfony app heavily uses forms for API/input validation (e.g., REST, GraphQL, or admin panels).
  • You’re tired of writing repetitive form submission logic (e.g., new FormType(), $form->submit($request), $form->isValid()).
  • You need consistent validation across endpoints (e.g., ensuring all POST /users requests validate email formats via the same form type).
  • Your team prioritizes developer velocity over micro-optimizations (e.g., avoiding custom resolvers for edge cases).
  • You’re using Symfony 7.4+ and PHP 8.2+ (compatibility is strict).

• Look Elsewhere If:

  • You need highly dynamic forms (e.g., runtime form type selection based on complex logic). This package relies on static form types or inference.
  • Your app uses non-Symfony request handling (e.g., custom middleware that bypasses Symfony’s argument resolvers).
  • You require fine-grained control over form submission (e.g., custom request parsing before validation). Use the RequestToFormMapper service for partial control, but expect trade-offs.
  • Your team prefers explicit over implicit: This package hides form creation/submission logic, which may conflict with debugging or testing needs.
  • You’re on Symfony <7.4 or PHP <8.2 (no support).

How to Pitch It (Stakeholders)

For Executives:

*"This package lets our backend team build API endpoints 30% faster by automating form submission and validation—no more writing repetitive boilerplate for every POST/PUT route. For example, instead of manually decoding JSON and validating fields, a controller like this now works in one line:

#[Route('/posts', methods: ['POST'])]
public function create(#[MapRequestToForm] Post $post) { ... }

This reduces bugs from manual validation, speeds up development, and keeps our codebase clean. The risk is minimal: it’s a battle-tested Symfony bundle with MIT license, and we can roll it back if needed. ROI: Faster feature delivery with less technical debt."*

For Engineering:

*"This solves a painful anti-pattern in Symfony apps: repeating the same form submission logic across controllers. Key wins:

• DRY: No more new FormType(), $form->submit($request) in every endpoint.
• Validation Consistency: All POST /users requests use the same form type, so rules (e.g., email format) are enforced uniformly.
• Flexibility: Works with entities, DTOs, or even scalar types (e.g., #[MapRequestToForm(TextType::class)] string $title). Supports PATCH/GET for partial updates or queries.
• Low Overhead: Just add #[MapRequestToForm] to your controller argument. For edge cases (e.g., custom form options), use the RequestToFormMapper service. Trade-offs:
• Not a silver bullet for dynamic forms (form types must be registered).
• Validation errors throw HTTP 422 by default (can be customized). Recommendation: Pilot this on 2–3 new API endpoints first to validate the DX before wider adoption."*

For Developers:

*"Imagine this:

// BEFORE (boilerplate)
public function update(Request $request, Post $post) {
    $form = $this->createForm(PostType::class, $post);
    $form->submit($request->getPayload());
    if (!$form->isValid()) { throw new ValidationException(); }
    $entityManager->flush($post);
    return $this->json($post);
}

// AFTER (clean)
public function update(#[MapRequestToForm] Post $post) {
    $entityManager->flush($post);
    return $this->json($post);
}

Why this is awesome:

• No form creation/submission code in controllers.
• Automatic validation: Invalid requests throw early (HTTP 422).
• Works with Doctrine: Combine with #[MapEntity] for seamless updates.
• Supports queries: Use #[MapRequestToForm(acceptFormat: 'query')] for GET filters. Gotchas:
• Form types must be registered (but you’re already doing that).
• Custom form options? Use formOptions in the attribute or the mapper service. Try it: Replace one form-heavy endpoint and compare the diff."*