Symfony Json Form Laravel Package

Product Decisions This Supports

• Build vs. buy for server-driven product forms: v1.3.0 ships a runnable .example/ product editor covering every shipped element type, context-hook value objects, and React rendering against both formV1 and formV2. This gives product and engineering a concrete reference for evaluating whether to build form/DTO infrastructure in-house or adopt the package.
• Roadmap for schema evolution: The example’s dual formV1/formV2 rendering and derived initial values demonstrate a path for versioned form schemas, supporting phased rollouts and backwards-compatible form migrations.
• Prioritizing commerce and admin workflows: The JSON body fix addresses JavaScript clients sending whole numbers such as 150 for a float price field. This directly affects product editors, pricing forms, and any PHP/React flow where browser JSON is denormalized into typed DTOs.
• Extensibility without forking: New overridable hasJsonBody() and constructDto() methods let teams tailor request handling and rendering decisions, which supports product-specific form services and custom DTO construction.
• Reducing edge-case support burden: Restored support for DTO subclasses in render() and handleRequest(), plus package-level exceptions for DTOs that cannot be constructed without arguments, improves reliability for teams populating DTOs in place or building DTOs dynamically.
• Frontend integration and bundling compatibility: React sources now use import type, and tsconfig.json enables verbatimModuleSyntax, reducing friction for host applications with stricter TypeScript or bundling configurations.
• Use cases: Product editors, product nomenclators, admin panels, CMS-style entity forms, typed DTO-backed forms, and React frontends that need to render server-defined form JSON with versioned schemas.

When to Consider This Package

• Strong fit when: The stack is Laravel/PHP with a React frontend, forms are backed by typed DTOs, and the team wants a shared contract between PHP form services and React rendering.
• Strong fit when: You need server-driven forms, multiple form schema versions, custom element types, context hooks for value objects, or a product-editor-style reference implementation to validate the approach.
• Strong fit when: You want to keep form behavior and DTO hydration close to Laravel while still rendering the same JSON contract in React.
• Consider carefully when: Your frontend is not React, your backend is not Laravel/PHP, or your forms are simple enough that a lightweight form library plus standard validation would be cheaper.
• Look elsewhere when: You need a fully hosted, low-code form builder with no custom PHP/React integration work; when you do not want package-specific abstractions around form services and DTOs; or when the team cannot adopt the package’s conventions for JSON bodies, DTO classes, and schema versioning.
• Pilot before committing: Use the new .example/ and --example validation path as an adoption gate. If the example’s product-editor patterns do not map to your domain, the package is likely a poor fit.

How to Pitch It (Stakeholders)

For executives: This package reduces duplicated form and DTO logic between Laravel and React, accelerating delivery of product editors and admin workflows. v1.3.0 adds a runnable reference product editor and fixes a real JavaScript-to-PHP numeric handling issue that could block price and quantity forms. It also restores DTO subclass support and improves error reporting, lowering integration and support risk. It is best positioned as a build accelerator for Laravel/React teams, not as a replacement for a hosted form builder.

For engineering: The release tightens the PHP/React contract: JSON request bodies are now denormalized with the correct format, float properties accept JavaScript’s whole-number representation, DTO subclasses are accepted via instanceof guards, and unbuildable DTOs surface as package exceptions with form and DTO context. New overridable methods provide controlled extension points, while the React type-import changes improve compatibility with strict TypeScript and host bundlers. The expanded example and test-suite updates make the package easier to validate before adoption.

For product: The package supports versioned, server-defined forms and complex product nomenclators without duplicating field definitions across backend and frontend. The new example demonstrates every shipped element type and both schema versions, making it easier to assess fit, estimate effort, and de-risk a pilot.