Laravel Reactions Laravel Package

Getting Started

• Install with Composer: composer require ritechoice23/laravel-reactions.
• Publish and run the package config/migrations using the tags documented in the README. Typical flow:

  php artisan vendor:publish --tag=laravel-reactions-config
  php artisan vendor:publish --tag=laravel-reactions-migrations
  php artisan migrate
  

• Define your reaction vocabulary early in config: like, love, celebrate, etc. Treat these strings as part of your public API contract.
• Add the package’s reactable trait to models that receive reactions, e.g. Post, Comment, Video. Add the reactor trait to the model that reacts, usually User.
• First use case to wire up: an authenticated user toggles a reaction on a post, then the UI receives the new count and the current user’s reaction.
• Look first at:
  1. The README for trait names and method signatures.
  2. The published config for allowed reaction types.
  3. The migration for polymorphic columns, indexes, and uniqueness constraints.
  4. The traits for the exact react / unreact / toggle methods exposed by 1.0.0.

Implementation Patterns

• Keep reaction types server-validated. Never accept arbitrary strings from the client:

  $data = $request->validate([
      'type' => ['required', Rule::in(config('reactions.types'))],
  ]);
  

• Use the package’s toggle/react methods inside your controller or action class, then return a small API payload:

  $post->toggleReaction($data['type'], $request->user());
  
  return response()->json([
      'counts' => $post->reactionCounts(),
      'mine' => $post->reactionFor($request->user()),
  ]);
  

  Verify exact method names against the installed package; at 1.0.0 these are the primary public surface you will use day to day.
• Authorize before reacting. Use a policy or gate to answer “can this user react to this model?” — especially for private posts, locked threads, archived records, or tenant-scoped content.
• Add reaction summaries to API resources rather than letting the frontend infer state:

  return [
      'id' => $post->id,
      'reactions' => [
          'counts' => $post->reactionCounts(),
          'mine' => $post->reactionFor(auth()->user()),
      ],
  ];
  

• Eager-load reaction counts or summaries when listing many models. Avoid loading full reaction collections just to count them.
• Use route model binding and scoped bindings for nested resources, e.g. /posts/{post}/reactions/{type}.
• For changing a reaction, prefer a single toggle/update endpoint. If the package models one reaction per user per reactable, a toggle is enough. If it models multiple reaction types per user, be explicit about whether “change reaction” means replace or add.
• Consider emitting domain events after a reaction changes: PostReacted, PostReactionRemoved, or your own wrapper event. Use these for notifications, activity feeds, and analytics without blocking the request with heavy work.
• Test the important paths: duplicate reaction attempts, toggling off, changing reaction type, unauthorized reactions, and models with no reactions.
• If the package exposes scopes or query helpers, use them in feed queries rather than hand-joining the reactions table.

Gotchas and Tips

• 1.0.0 is the first stable release and the release notes only link to the changelog. Treat the README, config, and migration as the source of truth, and pin ^1.0 until you have a reason to move.
• Polymorphic columns can be fragile. Use Laravel morph maps if model class names are likely to change, and add indexes on reactable_type, reactable_id, reactor ID, and reaction type.
• Race conditions matter. Two simultaneous toggles can create duplicates if a unique constraint is missing. Add the unique index the package ships with or create one that matches your intended rule.
• Avoid counting by loading collections. $post->reactions->count() inside a loop causes N+1 queries; use the package’s count helper or a database aggregate.
• Validate reaction types against config, not against frontend constants. Changing config later should not silently break existing rows; migrate data if you rename reaction types.
• Decide what happens when a reactable is deleted or soft-deleted. You may need an observer or cleanup command to remove orphaned reactions.
• After changing reaction config, clear config cache in local/dev with php artisan config:clear. In production, deploy config changes deliberately.
• If using package events, queue listeners for notifications and feed fan-out. Reaction endpoints should stay fast.
• For optimistic UI, make toggles idempotent and reconcile with the server’s returned counts. Do not let the frontend be the only source of truth.
• If you support multiple guards or teams, confirm how the package identifies the reactor. You may need to pass the reactor explicitly or scope reactions by tenant/team.
• Before exposing reaction type strings in your API, document them as stable values. Renaming like to thumbs_up later is a breaking client change.