AddIgniteUIBlazor fix loading modules in settings overload, docs and test coverage

[damyanpetev]

Delayed docs for AddIgniteUIBlazor since they should be payed special attention and there was a bug that was again discovered during #286 that's fixed and test coverage is a added since it was missing entirely.

AddIgniteUIBlazor(settings) silently discarded any resource modules the settings already carried, so preloading through the settings object never worked unless the same list was repeated as params.

The bug

Two adjacent lines in the settings overload:

var bs = new IgniteUIBlazorSettings(settings);          // copy ctor carries ModulesToLoad over
bs = bs.WithModulesToLoad(modulesToLoad != null && modulesToLoad.Length > 0
    ? new ReadOnlyCollection<Type>(modulesToLoad)
    : null);                                            // ...and this nulls it right back

WithModulesToLoad assigns unconditionally, so with no params the null wins:

var settings = IgniteUIBlazorSettings.Create().WithModulesToLoad(new([typeof(IgbTreeModule)]));
services.AddIgniteUIBlazor(settings);   // preloads nothing

The copy constructor deliberately preserving ModulesToLoad is what makes this read as an oversight rather than a decision — one line puts the list in, the next takes it out.

The fix

The params now add to what the settings carry instead of replacing it, de-duplicated and settings-first:

Type[] modules = [.. (settings?.ModulesToLoad ?? Enumerable.Empty<Type>())
    .Concat(modulesToLoad ?? Enumerable.Empty<Type>())
    .Distinct()];
bs = bs.WithModulesToLoad(modules.Length > 0 ? new ReadOnlyCollection<Type>(modules) : null);

Tests

There was no coverage for AddIgniteUIBlazor or IgniteUIBlazorSettings at all — the types appeared only in the TestBed's Program.cs and the interop harness, never asserted. ServiceRegistrationTests now covers:

• both overloads register IIgniteUIBlazorSettings and IIgniteUIBlazor, and return the collection for chaining;
• no modules leaves ModulesToLoad null;
• params modules surface in the settings;
• modules on the settings survive with and without params, de-duplicated when listed twice;
• the other settings (ForceJsonDataMarshalling) survive the copy;
• the runtime invokes each listed module's static Register, once per scope — which is what preloading actually means, rather than just checking the list.

Two of them fail against the old code, verified by reverting the fix.

Verification

dotnet build clean; unit suite 891 passed, 0 failed.

[Copilot]

Pull request overview

Updates the AddIgniteUIBlazor DI extension docs and fixes how the settings-based overload composes ModulesToLoad, backed by new unit tests to prevent regressions in service registration and module preloading behavior.

Changes:

• Added XML documentation to AddIgniteUIBlazor overloads describing runtime registration and optional module preloading.
• Fixed the settings overload to merge modules from the provided settings with the params modules (instead of replacing/clearing them).
• Added unit tests covering service registration, module list composition/deduplication, and module Register invocation behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
tests/IgniteUI.Blazor.Tests/ServiceRegistrationTests.cs	Adds coverage for AddIgniteUIBlazor service registration and module list composition/registration behavior.
src/componentsBase/InfragisticsBlazorExtensions.cs	Adds docs and fixes module list merging behavior for the settings-based registration overload.

Suppressed comments (1)

tests/IgniteUI.Blazor.Tests/ServiceRegistrationTests.cs:132

• This test resolves the scoped runtime from the root provider. To better reflect real-world Blazor DI (and to keep the module-registration assertion tied to the scoped lifetime), resolve the runtime from an explicit scope.

        using var provider = Build(s => s.AddIgniteUIBlazor(typeof(FirstModule), typeof(SecondModule)));
        var runtime = provider.GetRequiredService<IIgniteUIBlazor>();

        Assert.Same(runtime, Assert.Single(FirstModule.Registrations));
        Assert.Same(runtime, Assert.Single(SecondModule.Registrations));
    }

[damyanpetev]

@copilot That'd be a bit out of scope for this PR, so attempt a fix in a separate PR against master

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/componentsBase/InfragisticsBlazorExtensions.cs:85

• settings is already dereferenced on the previous line (new IgniteUIBlazorSettings(settings)), so the null-conditional settings?.ModulesToLoad is redundant and can misleadingly suggest null is supported here. Consider using settings.ModulesToLoad for clarity.

                    Type[] modules = [.. (settings?.ModulesToLoad ?? Enumerable.Empty<Type>())
                        .Concat(modulesToLoad ?? Enumerable.Empty<Type>())
                        .Distinct()];

[Copilot]

@damyanpetev I've opened a new pull request, #313, to work on those changes. Once the pull request is ready, I'll request review from you.