Refactor: add strongly typed serialization objects

[tesar-tech]

Description

Draft for strongly-typed options, currently focused on the button and color picker components. I need your feedback to continue further.

Closes #5701

Key Points

• Type Changes: Updated from object to TheComponentJsOptions in JsModule and its interface, as well as when calling methods in the module (typically within TheComponent.razor.cs).
• Using record Types: Given that we're targeting .NET 6, the required keyword isn’t available. Using record types is a suitable alternative, as it allows for clean initialization without needing SomeProperty = SomeProperty declarations. This makes both the definition and initialization more concise. It can be of course done the "old way", but I don't see any advantage there.
• File Organization: The JsOptions files are organized within a JsOptions folder. I followed the codebase conventions, placing everything within the Blazorise namespace.

Questions

• Interfaces for JsModules: I’m unclear on the purpose of having interfaces for JsModules, especially since each one seems to have only one implementation without further usage. It feels like an extra step when working with these modules. (Is there a particular rationale here?)

Future Improvements

• Unified JsOption Structure in TypeScript: It would be beneficial to have a consistent JsOption DTO structure on the js side. This would involve introducing ts, which could greatly enhance readability and error-checking. With source generators, we could automate much of this without requiring manual duplication of JsOption on both sides. This transition could be done gradually, component by component, for a smooth adoption.

[tesar-tech]

I have a question about internal vs public data types in options. @stsrki

Currently, VideoJSOptions is internal, which prevents it from being used in a public module method:

    public virtual async ValueTask Initialize(DotNetObjectReference<Video> dotNetObjectReference, ElementReference elementRef, string elementId, VideoInitializeJSOptions options)

One solution could be to make the JSModule methods internal as well. Is there any reason not to, or are people actively calling these methods?

Alternatively, we could make all *JSOptions classes public, but placing them in the main Blazorise namespace might not be ideal. Would moving them to a dedicated namespace be a better option?

Second question is about the interfaces for the JS modules, as I already asked in the PR description—do we really need them? For example, the JSVideoModule doesn’t have an interface and seems to work just fine.

[stsrki]

I have a question about internal vs public data types in options. @stsrki

Currently, VideoJSOptions is internal, which prevents it from being used in a public module method:

    public virtual async ValueTask Initialize(DotNetObjectReference<Video> dotNetObjectReference, ElementReference elementRef, string elementId, VideoInitializeJSOptions options)

One solution could be to make the JSModule methods internal as well. Is there any reason not to, or are people actively calling these methods?

Alternatively, we could make all *JSOptions classes public, but placing them in the main Blazorise namespace might not be ideal. Would moving them to a dedicated namespace be a better option?

Second question is about the interfaces for the JS modules, as I already asked in the PR description—do we really need them? For example, the JSVideoModule doesn’t have an interface and seems to work just fine.

It might be that, in this case, VideoJSOptions was made public by accident. Not sure. But generally, we expose it as public in case we, or our users, need to do unit testing on the JS modules. Which, in turn, requires that JS options also be made public.

[stsrki]

Overall looks good: But there are still few things:

• all public classes and properties must have XML comments written. If you don't already a GH copilot is good with it. And you can also use chatgpt to generate them,
• Please use VS instead of Rider if you can. I see a lot of formating broken. Or if Rider can use .editorconfig then configure it.

[stsrki]

• Please use VS instead of Rider if you can. I see a lot of formating broken. Or if Rider can use .editorconfig then configure it.

PS. https://www.jetbrains.com/help/rider/Using_EditorConfig.html#roslyn