Getting Started

Install the package, publish its config and migrations, and run migrate to get the submissions table before touching any form code.
Start in the docs index / README. In v1.4.0 the Features list is now one line per area, and the field type reference lives in a table under Building a form — that table is the fastest way to pick the field types you need.
First use case: define a form as a field definition (stored as JSON, including each field's options), render it, and read the results in the panel. Use the Blade renderer for public/marketing pages and the Livewire renderer when you need an interactive form.
If you want star ratings, install packstub/filament-rating. Nothing to wire up — it is detected automatically and only changes how ratings are displayed.

Implementation Patterns

One definition, two renderers. Keep the field definition in a single place (the stored JSON) so the Blade renderer, the Livewire renderer, and the preview never drift apart.
Choices are data. Radio buttons and checkbox lists keep their choices — and now their column count — in the field's options. Set Columns (up to four) on the field and the layout follows in Blade, Livewire, and the panel; it round-trips through the JSON definition.
Ratings as presentation. Store the score as you always have. Install the rating package to get the star input, the average/distribution column, the "4 stars & up" filter, and stars in submission details; remove it and everything still works with plain rendering.
Custom detail rows. A field type can supply its own submission-details entry via detailEntry() — good for domain-specific summary lines (e.g. computed totals, linked records) that shouldn't live in a generic value dump.
Preview early, render often. Preview and the Livewire renderer share components, so after changing a field type or column layout check both plus the submissions table.
Parity workflow. Build and review forms with the rating package installed to see the intended look, then smoke-test a build without it to confirm graceful degradation.

The rating integration is cosmetic by design: the stored score is unchanged, so installing or removing the package must not alter reporting. Don't write logic that assumes the star UI exists.
Detection, not requirement — verify the package is present in both your local and production lockfiles. If it's missing, you silently get the non-star renderer and no error.
Column counts live in the field's options, so editing a live form's definition changes the layout for existing submissions' detail views too. Treat definition edits as content changes, not just code changes.
The star column sorts the score numerically (10 after 9) on MySQL and Postgres. If you add your own sortable columns over scores, don't let them sort as strings.
Choices collapse to a single column on small screens; don't author four-column option sets that only make sense read left-to-right as a sequence.
detailEntry() runs per submission row — keep it cheap and escape its output, since it renders inside the details view.
Docs churn: the README Features section is condensed and field types moved under Building a form. Update internal links and bookmarks pointing at the old anchors.