using AyCode.Core.Enums;
using AyCode.Core.Loggers;
using AyCode.Core.Serializers.Binaries;
using AyCode.Services.Loggers;
using AyCode.Services.SignalRs;
using Microsoft.Extensions.Logging.Abstractions;

namespace FruitBank.Common.Loggers
{
    /// <summary>
    /// FruitBank log-feltöltő: LogItemClient wire-típussal, AcBinary-protokollon (egységes a fbHub-bal).
    /// Cél: {BaseUrl}/loggerHub — a BaseUrl-t a host hidratálja az appsettings-ből.
    /// </summary>
    public class SignaRClientLogItemWriter : AcSignaRClientLogItemWriter<LogItemClient>
    {
        public SignaRClientLogItemWriter() : this(AppType.Web, LogLevel.Detail, null)
        {
        }
        public SignaRClientLogItemWriter(AppType appType, LogLevel logLevel, string? categoryName = null)
            : base($"{FruitBankConstClient.BaseUrl}/{FruitBankConstClient.LoggerHubName}", appType, logLevel, categoryName, CreateProtocolOptions())
        {
        }

        // ⚠️ VÉGTELEN-CIKLUS VESZÉLY — NE ADJ LOGGERT A PROTOKOLLNAK! ⚠️
        // Ez a writer maga A log-feltöltő csatorna. Ha a protokoll loggert kapna (LoggerClient, ILogger, bármi,
        // ami ebbe a writerbe torkollik), akkor minden feltöltés sorosítása ÚJABB log-sorokat termelne
        // (Serialize start / WriteArgument / ...), amiket ez a writer megint felküldene → sorosítás → log → ...
        // → robbanó visszacsatolás, a kliens másodpercek alatt megfullad.
        // Ezért a Logger EXPLICIT NullLogger.Instance (nem null! — a null-t az AddAcBinaryProtocol ??= fallbackje
        // a DI ILogger<AcBinaryHubProtocol>-jával pótolná, ami visszahozná a hurkot).
        // Ugyanezért erre a hub-builderre AddAcDefaults/ConfigureLogging SOHA nem kerülhet.
        private static AcBinaryHubProtocolOptions CreateProtocolOptions() => new()
        {
            ProtocolMode = BinaryProtocolMode.Bytes, // WASM-safe, ugyanaz, mint az fbHub-on
            Logger = NullLogger.Instance,            // süket logger — ld. a fenti figyelmeztetést
        };
    }
}