<?php
/**
 * Client Service Provider Class
 *
 * @package Easy_Invoice
 * @subpackage Providers
 */

namespace EasyInvoice\Providers;

use EasyInvoice\Interfaces\ClientRepositoryInterface;
use EasyInvoice\Repositories\ClientRepository;

/**
 * ClientServiceProvider Class
 * 
 * Handles registration of client-related services.
 */
class ClientServiceProvider {
    /**
     * The repository instance
     *
     * @var ClientRepositoryInterface
     */
    protected static $repository = null;
    
    /**
     * Register client services
     */
    public function register() {
        // Register the `customer` role on init:1.
        //
        // This was previously hooked to `after_setup_theme` from inside
        // a callback that itself only runs on init:10 — so by the time
        // add_action() was called, `after_setup_theme` had already fired
        // and the registration silently never ran. On sites without
        // WooCommerce (which also registers `customer`), the role stayed
        // unregistered, WP_User::roles filtered it out as unknown, and
        // the Clients page fell back to a "Client" label while WC sites
        // showed "Customer" for the same data.
        add_action('init', [$this, 'registerClientRole'], 1);

        // Register client repository
        $this->registerClientRepository();
    }

    /**
     * Register client role if it doesn't exist.
     *
     * Idempotent — short-circuits when WooCommerce (or anything else)
     * has already registered the role. Two implications worth knowing:
     *
     * 1. We register WITHOUT the `read` capability. On a site that
     *    never had WooCommerce, existing 'customer'-role users had no
     *    effective `read` cap because the role wasn't registered at
     *    all (and `WP_User::has_cap` couldn't pull `read` from a role
     *    that didn't exist). Registering with `['read' => true]` here
     *    would silently UPGRADE those users — granting wp-admin access
     *    they never had. We pass `[]` so the registration only fixes
     *    the display label, not the cap surface.
     *
     * 2. On a site WITH WooCommerce, WC has already registered
     *    'customer' with its full cap set (including `read`). Our
     *    add_role() is a no-op there — get_role() returns truthy and
     *    we bail. WC customers retain WC's caps unchanged.
     */
    public function registerClientRole() {
        if (get_role('customer')) {
            return;
        }
        add_role(
            'customer',
            __('Customer', 'easy-invoice'),
            []
        );
    }
    
    /**
     * Register client repository
     */
    protected function registerClientRepository() {
        // Create and store the repository instance
        self::$repository = new ClientRepository();
    }
    
    /**
     * Get the client repository
     *
     * @return ClientRepositoryInterface The client repository
     */
    public static function getClientRepository() {
        // Create the repository if it doesn't exist
        if (self::$repository === null) {
            self::$repository = new ClientRepository();
        }
        
        return self::$repository;
    }
}