Larahooks Laravel Package

Getting Started

• Install via Composer: composer require realzone22/larahooks (verify package name from repository).
• Publish any config/service provider if the package requires it (check README for vendor:publish).
• First place to look: the package's README.md and src/ directory to understand the hook registration API.
• Minimal first use case: register a simple action hook in a service provider and trigger it from a controller or model event.

  // In a service provider
  Hook::addAction('user.registered', function ($user) {
      // send welcome email
  });
  
  // Elsewhere
  Hook::doAction('user.registered', $user);
  

• If the package uses a facade, add it to config/app.php aliases (for Laravel < 5.5) or rely on auto-discovery.

Implementation Patterns

• Service provider registration: Register all hooks in a dedicated HookServiceProvider to keep them centralized. Use boot() for actions and register() only if you need to bind services.
• Action vs. filter pattern: If LaraHooks mirrors WordPress-style hooks, use actions for side effects (logging, notifications) and filters for modifying data (e.g., Hook::applyFilters('user.name', $name)).
• Priority ordering: Most hook systems support priority arguments. Use them to control execution order, especially when multiple packages or modules add hooks to the same name.
• Integration with Laravel events: You can bridge LaraHooks with Laravel’s native event system by dispatching events inside hook callbacks, or by using LaraHooks as a lightweight alternative when you need named, string-based hooks without event classes.
• Testing: In tests, clear registered hooks between test cases (if the package provides a Hook::clear() method) to avoid cross-test contamination.
• Modular packages: Use LaraHooks to allow other packages to extend your functionality without tight coupling—document your hook names as part of your public API.

Gotchas and Tips

• Sparse documentation: As a 1.0.0 initial release, the README may lack examples. Inspect the source (src/Hook.php, facades, service provider) to understand available methods.
• Naming collisions: Hook names are global strings. Prefix them with your package name (e.g., myplugin.user.registered) to avoid conflicts.
• Performance: Each hook call iterates over registered callbacks. Avoid registering hooks in hot paths (e.g., inside loops) and consider caching if you have many hooks.
• Debugging: If a hook isn’t firing, check that the service provider is registered, the hook name matches exactly, and the callback signature matches the arguments passed.
• Extension points: The package may expose a config file for default priorities or a way to disable hooks. Publish and review config/larahooks.php if available.
• Version pinning: Since this is the first stable release, pin to ^1.0 and watch for breaking changes in minor releases until the API stabilizes.