/**
 * Frontend Notifications Domain Service
 *
 * Handles IN_APP notifications only. Email, SMS, and Push notifications
 * are backend-only operations via @plyaz/notifications package.
 *
 * Uses inherited methods from BaseFrontendDomainService:
 * - fetchAll() - inherited (GET /notifications via @plyaz/api)
 * - delete() - inherited (DELETE /notifications/:id via @plyaz/api)
 *
 * Streaming support:
 * - Real-time in-app notification updates (created, updated, deleted, read, unread)
 *
 * Runtime: Frontend (React, Next.js, etc.)
 *
 * @example
 * ```typescript
 * const service = await getFrontendNotificationsDomainService();
 *
 * // List and delete in-app notifications
 * const items = await service.fetchAll({ status: 'queued' });
 * await service.delete('notification-id');
 * ```
 */
import type { CoreServiceCreateOptions, CoreBaseValidatorInstance, CoreStreamHandlerDeclaration, CoreStreamHandlerIds } from '@plyaz/types/core';
import type { NotificationsFrontendStoreSlice, NotificationsFrontendStoreData, NotificationStoreItem } from '@plyaz/types/store';
import { BaseFrontendDomainService } from '../base';
import { NotificationsMapperClass } from './mappers/NotificationsMapper';
import type { NotificationsEntity, NotificationsResponseDTO, CreateNotificationsDTO, PatchNotificationsDTO, QueryNotificationsDTO, NotificationsFrontendServiceConfig } from '@plyaz/types/core';
/**
 * Frontend Notifications Domain Service
 *
 * Extends BaseFrontendDomainService with all generic types.
 * All CRUD methods are inherited from base class.
 *
 * Inherited from BaseFrontendDomainService:
 * - fetchAll() - list all notifications
 * - delete() - delete a notification
 */
export declare class FrontendNotificationsDomainService extends BaseFrontendDomainService<NotificationsFrontendServiceConfig, NotificationsFrontendStoreSlice, NotificationsFrontendStoreData, NotificationsEntity, NotificationsResponseDTO, CreateNotificationsDTO, PatchNotificationsDTO, QueryNotificationsDTO, NotificationStoreItem, InstanceType<typeof NotificationsMapperClass>, CoreBaseValidatorInstance, void> {
    /** Service key for registry */
    static readonly serviceKey: "notifications-frontend";
    /**
     * Primary store key for this service.
     * Used by ServiceRegistry to auto-inject the store.
     * Must be static for base class constructor to access.
     */
    static readonly primaryStoreKey: "notifications";
    /** Event prefix for all events emitted by this service */
    protected eventPrefix: string;
    /**
     * Factory method for ServiceRegistry auto-initialization.
     * Auto-registers event handlers for store updates.
     */
    static create(config?: NotificationsFrontendServiceConfig, options?: CoreServiceCreateOptions): Promise<FrontendNotificationsDomainService>;
    /** Stream handler IDs - overrides base class pattern */
    protected static readonly STREAM_HANDLER_IDS: CoreStreamHandlerIds<'LISTENER'>;
    /** Default priority for stream handlers */
    private static readonly DEFAULT_HANDLER_PRIORITY;
    /**
     * Declarative stream handlers - auto-registered by base class
     * Handles real-time in-app notification delivery.
     *
     * Only notification:created is needed - user receives new notifications.
     * User subscribes to user:notifications:{userId} channel.
     */
    protected static readonly STREAM_HANDLERS: CoreStreamHandlerDeclaration[];
    private static _eventHandlersRegistered;
    /**
     * Register event handlers for cross-service event reactions.
     * Auto-called by create() method when service is initialized.
     *
     * IMPORTANT: When to use this vs storeHandlers in service config:
     *
     * **Use storeHandlers (service config)** for:
     * - Simple, automatic store updates (addData, removeData, updateData)
     * - Loading state management for THIS service's operations
     * - Primary store population from API responses
     * - Straightforward CRUD → store sync
     *
     * **Use FrontendEventPersistenceHandler (this method)** for:
     * - Listening to events from OTHER services (cross-domain reactions)
     * - Updating DIFFERENT stores based on events (not just primary store)
     * - Complex conditional logic (e.g., block API calls when X event fires)
     * - Side effects that storeHandlers cannot achieve
     * - Coordinating multiple stores on a single event
     *
     * @example Cross-domain reaction
     * ```typescript
     * // When auth:logout fires, clear this domain's cached data
     * 'auth:logout': {
     *   handler: (store) => store.clearAll(),
     * }
     * ```
     *
     * @example Conditional logic
     * ```typescript
     * // Disable feature when maintenance mode event fires
     * 'system:maintenance:started': {
     *   handler: (store) => store.setDisabled(true),
     * }
     * ```
     *
     * @param verbose - Enable verbose logging
     * @returns Cleanup function to unregister all handlers
     */
    static registerEventHandlers(verbose?: boolean): () => void;
    constructor(config?: NotificationsFrontendServiceConfig, options?: CoreServiceCreateOptions);
    isAvailable(): boolean;
    dispose(): void;
}
/**
 * Get or create singleton instance
 */
export declare function getFrontendNotificationsDomainService(config?: NotificationsFrontendServiceConfig, options?: CoreServiceCreateOptions): Promise<FrontendNotificationsDomainService>;
/**
 * Lazy singleton proxy - creates instance on first access
 */
export declare const frontendNotificationsDomainService: FrontendNotificationsDomainService;
/**
 * Reset singleton (for testing)
 */
export declare function resetNotificationsFrontendService(): void;
//# sourceMappingURL=FrontendNotificationsDomainService.d.ts.map