Getting Started

v1.0.0 is the first stable tag, but the release notes only link to the full changelog. Start with the package README and CHANGELOG/commit comparison before adopting.
Install with composer require modularavel/favoritable, publish any config/migrations exposed by the service provider, then run php artisan migrate.
Add the package’s favorites trait to your actor model (usually User) and the favoritable trait to models that can be favorited. Confirm exact trait names from the README.
First use case: let a user favorite a post, then query it back: $user->favorite($post), $user->hasFavorited($post), and $post->favorites()->count(). If the API differs, wrap it in a small app service so controllers do not depend directly on package method names.
Look first at the migration, config file, and traits. The migration tells you the table shape and uniqueness constraints; the config tells you whether table/model names are overridable.

Implementation Patterns

Build idempotent toggle endpoints around favorite/unfavorite actions. Return the new state and count so frontends do not need a second request.
Use polymorphic favorites for multiple favoritable types, but enforce a morph map so stored type strings remain stable if class namespaces change.
Eager load favoritable relations when listing a user’s favorites, and use withCount or cached counters for “popular” listings to avoid N+1 queries.
For API resources, expose is_favorited on list endpoints by preloading the authenticated user’s favorite IDs rather than calling hasFavorited per item.
If the package dispatches events, hook notifications/activity logs there. If not, put favorite/unfavorite in an application service and dispatch your own domain events.
For high-traffic counts, cache favorite totals per favoritable model and invalidate on create/delete. Keep the database as source of truth.
Test with model factories and RefreshDatabase; cover duplicate favorites, unfavoriting something not favorited, and authorization boundaries.

The v1.0.0 notes do not list breaking changes or migration steps. Pin ^1.0, read the changelog, and verify the README against the installed tag before upgrading later.
Duplicate favorites should be prevented by a unique index. Use firstOrCreate or catch constraint violations; do not rely on UI state alone.
Decide what happens to favorites when a favoritable model is soft-deleted or force-deleted. Add cleanup jobs, cascading deletes, or explicit scopes depending on whether history should survive.
Changing model class names without a morph map can orphan existing favorites. Set Relation::enforceMorphMap before production data exists.
Protect favorite endpoints with auth middleware and verify the actor model actually uses the package trait.
If table/model names are configurable, keep config, migration, and custom model overrides aligned. Clear/cache config after deployment.
Debug by inspecting the favorites table columns (user_id, favoritable_type, favoritable_id) and indexes. Missing indexes will hurt count and “has favorited” queries.
Extension points to check: custom Favorite model, configurable table/model, events/observers, and any query scopes for popular or recent favorites.