Laravel Model Index Laravel Package

Getting Started

• Install with composer require aw-studio/laravel-model-index and publish any package config if your app needs to override defaults.
• Start with the package README and the index class/trait you attach to a model. Define an index for one admin-facing model first, e.g. OrderIndex.
• First use case: build a table index with filters, sorting, and pagination. In v0.1.6, a filter such as status can accept multiple values, so a multi-select “Status” filter can return all matching rows in one query.

Implementation Patterns

• Define allowed filters in the index class rather than reading arbitrary request keys in controllers. Keep the filter contract close to the model/index definition.
• Existing single-value filters continue to work as scalar filters, e.g. ?filter[status]=paid.
• For the new multi-value behavior, send array-style filter params such as ?filter[status][]=draft&filter[status][]=published. The package should translate this into an whereIn-style constraint for index queries.
• Use multi-value filters for common day-to-day admin workflows: status multi-selects, category pickers, owner/assignee filters, and tag-like filters where users expect “any of these values”.
• Combine array filters with other scalar filters, sorting, and pagination. Keep the array shape consistent on the frontend so the package receives an actual array, not a comma-separated string.
• For complex cases, use custom filter methods/closures in the index class and delegate to whereIn, relationship constraints, or scoped queries as needed.
• Add feature tests around array filters: one value, multiple values, empty array, invalid values, and combined filters. Assert both the result set and that the generated query uses the expected constraint.

Gotchas and Tips

• Do not assume comma-separated values are supported just because array filters are. Send real arrays (filter[status][]=...) unless the package docs explicitly describe another syntax.
• Validate and allowlist filter keys and values. Multi-value filters can grow unbounded, so cap the number of accepted values or reject oversized arrays.
• Handle empty arrays deliberately. An empty multi-select should usually mean “no filter” or “return no rows” depending on product behavior; make that choice explicit and test it.
• Cast values before applying filters where needed, especially IDs, enums, and booleans. Array filters often expose type mismatches that scalar filters hide.
• Watch frontend serialization. Axios, fetch, and form encoders can serialize nested params differently; verify the request payload in browser dev tools or Laravel’s request dump.
• Debug with the underlying query: inspect the request filter payload, then use toSql()/query logging to confirm the package applies whereIn rather than separate orWhere clauses.
• Upgrade note: v0.1.6 is a feature addition, not an obvious breaking change. After upgrading, add regression tests for existing scalar filters and new multi-value array filters.
• Extension point: keep custom filtering logic in index classes or package-supported filter hooks rather than scattering it across controllers; this keeps index behavior reusable and easier to debug.