Ui Builder Laravel Package

Getting Started

• Require the package with Composer and, if the service provider isn't auto-discovered, register it. Publish any config/views the package ships (php artisan vendor:publish --tag=...) so you can override markup locally.
• Look first at the base component class — now UiComponent (renamed from HtmlComponent in v0.15.0). This is the single most important file: it defines how attributes are collected, merged, and rendered, and it's what your own components will extend.
• First use case: render a form component (input/select/textarea) with a label and a couple of attributes. The v0.15.0 label fix means labels now bind correctly to their controls out of the box, so this is a good smoke test that the upgrade landed cleanly.
• If you're upgrading, do a project-wide search for HtmlComponent before anything else — see Gotchas.

Implementation Patterns

• Extending the base class. Custom components should extend UiComponent. This is the intended extension point and the thing the rename touches, so keep your subclass declarations in one place (or a shared abstract base of your own) to make future renames a one-line change.
• Attribute setting via the new methods. v0.15.0 adds methods for setting attributes on components. Prefer these over manually manipulating the attribute bag or interpolating strings into the template — they centralize merging/defaults and keep escaping consistent. Use them when:
  • a component needs to inject attributes conditionally (e.g. disabled, required, aria-*);
  • you want to layer defaults under caller-supplied attributes without losing the caller's values;
  • you're composing one component inside another and need to forward attributes.
• Form components. With labels fixed, standardize on passing the label through the component rather than hand-writing <label for="..."> next to it. Centralizing the label/for/id wiring is exactly the duplication this package exists to remove.
• Blade usage. Keep component invocations declarative (<x-...> with attributes) and push conditional logic into the PHP class, not into the template. This makes the new attribute methods useful rather than decorative.
• Integration tip: wrap the package's components in your own thin components if you expect churn. The rename in this release is a good argument for an internal indirection layer — one place to update, and your app's templates stay stable.

Gotchas and Tips

• Breaking change: HtmlComponent → UiComponent. This is a hard rename, not an alias (nothing in the notes suggests a compatibility shim). Audit:
  • extends HtmlComponent in your own components;
  • use statements and fully-qualified class references;
  • config files mapping component classes to tags;
  • any published views referencing the old class;
  • static analysis baselines and IDE caches. If you can't upgrade in one pass, pin the previous minor until the rename is done.
• Clear compiled views after upgrading: php artisan view:clear. Renamed classes plus changed label markup can leave stale compiled Blade files that produce confusing errors.
• Label fix may change rendered HTML. The fix likely alters for/id attributes or wrapper markup. Anything depending on exact output — snapshot tests, CSS selectors, JS querying by structure, e2e assertions — should be re-checked. Prefer selecting on stable hooks rather than DOM shape.
• Attribute precedence is the usual source of bugs. When a caller passes class or disabled and the component also sets a default, decide explicitly whether they merge or override. The new attribute methods make this configurable-ish; verify behavior with a quick render test rather than assuming.
• Debugging attributes: dump the component's attribute bag (or the final rendered string) in a throwaway Blade view to see what actually survived merging. Most "my class disappeared" reports are precedence, not escaping.
• Check the changelog for method signatures before adopting the new attribute methods broadly — notes say "new methods" without names, so confirm they're chainable and how they treat arrays vs. strings.
• Extension points to lean on: override the base class methods in your own subclass rather than editing published views, so package updates don't clobber your changes.