Weave Code
Ux Blocks Form Laravel Package
symfinity/ux-blocks-form
A Laravel package for Symfinity UX Blocks that provides reusable form field components and Blade blocks, making it easier to build consistent, customizable forms with validation and UX-focused styling for rapid form development.
Symfinity UX Blocks Form brings reusable, component-driven form blocks to Laravel applications. It lets you compose clean, accessible forms from configurable blocks while keeping validation, model binding, and Blade rendering predictable—ideal for teams standardizing form UX.
- Configurable blocks for common field types and layouts
- Laravel validation and old-input handling built in
- Fluent model binding and field configuration
- Accessible Blade components
- Extensible definitions for custom fields
Frequently asked questions about Ux Blocks Form
- How do I install symfinity/ux-blocks-form in a Laravel application?
- Install it with Composer using an exact pin, for example composer require symfinity/ux-blocks-form:0.1.3. The service provider is auto-discovered, and the package config and view files are publishable so you can customise the markup. Because the package is pre-1.0, run it in a single low-risk form first, such as an internal admin settings page, before rolling it out across your app.
- Which Laravel and PHP versions does symfinity/ux-blocks-form support?
- The available release metadata does not confirm a supported Laravel and PHP version matrix, so treat compatibility as unverified. Check the repository composer.json and any CI workflow, then run the package tests against your application's versions. Block wider adoption until that matrix is confirmed against your stack.
- Does symfinity/ux-blocks-form work with Inertia or a React or Vue SPA front end?
- Not directly. The package value is concentrated in server-rendered form markup, so it fits a standard Laravel monolith or modular monolith that renders forms server side. An Inertia or API-first SPA stack would need an adapter layer and would lose most of the benefit.
- Should I use a caret constraint like ^0.1 or pin an exact version?
- Pin exactly. Pre-1.0 SemVer permits breaking changes in minor releases, so a constraint like ^0.1.3 can pull in 0.2.0 with an incompatible public surface. Use an exact patch pin such as 0.1.3 and review the diff on every bump.
- Why do the v0.1.3 release notes contain no change details, and what should I check before upgrading?
- The v0.1.3 notes are a single pointer to CHANGELOG.md and declare no breaking changes, features, or deprecations, so the release content is unverified until you read the source. Review CHANGELOG.md and the diff, paying attention to views, validation handling, escaping, and dependency changes. Because form rendering sits on user-facing paths, add a changelog review gate to your pull request template so a silent patch change cannot become a customer-visible defect.
- Can I use these form blocks with Laravel validation errors and old input?
- Yes. The package is designed around Laravel's validation and old-input pipeline, with validation-ready field groups and compound inputs. Verify it on your own versions by spiking a form that fails validation and repopulates old input, then confirm error messages and field state render correctly.
- Does the package add a Node build step or pull in conflicting CSS and Tailwind dependencies?
- No Node build step is implied by the release metadata; the package ships native interaction CSS instead. The likelier risk is CSS class assumptions, such as a specific Tailwind version or a Blade UI kit, colliding with your existing front-end pipeline. Audit transitive dependencies and check publishable view and config paths for collisions before adopting.
- How do I keep symfinity/ux-blocks-form swappable so I can replace it later?
- Wrap every component you use in a thin internal facade, for example App\View\Components\FormInput, so the package appears in one file per component. Keep an exact version pin and a documented fallback to plain form partials. Done this way, removing the dependency should cost less than a sprint and stay a one-file change per component.
- Is it safe to render user-submitted data through these form components?
- There is no SECURITY.md or disclosure path documented in the available data, and escaping behaviour is not audited, so verify it yourself. Render payloads containing HTML tags and quotes through each input, label, and compound component and inspect the output for escaping. Also review accessibility regressions, since form markup on high-traffic pages has a customer-visible blast radius.
- Should I migrate my existing hand-rolled Blade forms to this package?
- No. Do not migrate existing forms; introduce the package alongside them in one non-critical form first. Budget roughly a day for the spike, review the rendered output and escaping, then decide go or no-go on wider usage. Greenfield adoption behind an internal wrapper component is the low-friction path.
Weaver
How can I help you explore Laravel packages today?