Laravel Reaction Laravel Package

Product Decisions This Supports

• Feature scoping for engagement/social interactions: v3.0.0 shifts the package from a generic “like” system to a broader reaction model (laravel-reaction, Reaction model, HasReaction trait, CanReact trait). This supports product decisions around moving beyond binary likes toward typed or richer reactions, if the roadmap calls for that.
• Build vs. buy for polymorphic engagement: If the product needs reactions on multiple entity types (posts, comments, users, etc.), this package now provides a more complete foundation: migrations, factories, events, config, exceptions, tests, and docs. That can reduce custom-build scope for a common but deceptively complex feature.
• Roadmap sequencing and upgrade planning: This is a breaking major release: package rename, model rename (Like → Reaction), trait rename (HasLike → HasReaction), migration/table changes, config changes, enum removal, and event renames. Any existing adoption of the prior “like” package requires a dedicated migration/upgrade workstream before new feature work.
• Data model and analytics decisions: The migration changes (likeable → reactable, new reaction table design, removed like-type enums) affect how reaction data is stored and reported. PM should confirm whether analytics, moderation, and reporting requirements are still met by the new schema.
• Use-case fit: Best suited to Laravel teams adding lightweight social reactions to existing models without building a full activity/feed system. Less suitable if the roadmap requires complex reaction taxonomies, heavy moderation workflows, or cross-service reaction aggregation.

When to Consider This Package

• Consider it when:
  • You are building a Laravel product that needs reactions on multiple model types and want a maintained, package-based starting point.
  • Your team prefers standard Laravel patterns: traits, models, migrations, factories, events, config, and service providers.
  • You need basic reaction infrastructure quickly and can absorb a major-version upgrade path.
  • You are standardizing on the renamed laravel-reaction concepts (Reaction, HasReaction, CanReact) and can plan data migration from any prior “like” implementation.
• Look elsewhere or build custom when:
  • You already have a stable “like” implementation and the product does not need the new reaction model; the breaking rename and migration cost may not be justified.
  • You need advanced reaction semantics beyond what this package exposes, such as weighted reactions, reaction aggregation pipelines, real-time counters at scale, or complex moderation.
  • You cannot tolerate a major-version migration now, or you need long-term API stability with no rename churn.
  • Your architecture is not Laravel-native or requires cross-service reaction storage.

How to Pitch It (Stakeholders)

• For executives: This release evolves a “likes” utility into a more complete reaction capability. It is a major version with breaking renames and schema changes, so treat it as a planned upgrade, not a drop-in patch. The value is faster delivery of engagement features and less custom code; the cost is a focused migration effort and regression testing.
• For engineering: v3.0.0 is a breaking redesign: package renamed to laravel-reaction, Like → Reaction, HasLike → HasReaction, new CanReact, changed migrations/config/events, removed like-type enums, added exceptions, factory, tests, and docs. Plan a migration for existing data and references, verify event listeners and config publishing, and budget for regression testing around reaction counts, polymorphic relations, and authorization.
• PM recommendation: Adopt only if the roadmap explicitly values richer reactions or if you are starting fresh. If the current “like” behavior is sufficient, defer the upgrade until a product need justifies the migration.