I am not sure I understand the issue correctly.

I guess it's about the Source/Blazorise/Components/Tooltip/Tooltip.razor.cs form the pr where you changed the PascalCase to camelCase so the tooltip library digest that correctly?

And you want to make sure it gets serialized like that (in camelCase ) no matter the externalities?

Can you describe the externalities?

To my understanding the camelCasing is already there. When the object arrives to js, all the propertyNames are already in camesCase and you really need to try hard to change that. There is no magic setting in System.Text.Json that can change that globally and this convention will hardly change...

Or did I misunderstood the issue completely @stsrki ?

There is no magic setting in System.Text.Json that can change that globally and this convention will hardly change...

@tesar-tech if I remember correctly the point is that the serializer could be configured in a global way that could affect any convention we might rely on. So we shouldn't rely on conventions that are susceptible to be changed, if they can be that is.
Is it not possible to configure the serializer in a global way? i.e change from camelcase convention to pascal case? I was under the impression it was possible.

@David-Moreira It is not possible dotnet/runtime#31094 and also marked as Not planned.

So far, when we serialized the object to JS, we relied mostly on the built-in JSON serializer, assuming everyone would have camelCase settings. But assuming it is not ideal and we need to handle it ourselves.

@tesar-tech The Tooltip you mentioned was just the first iteration of trying to solve the problem.

So, the plan is to have a dedicated serialization object with all the field names properly named using the JSON name attribute. We have already made it on the Video component. See:

• https://github.com/Megabit/Blazorise/blob/master/Source/Extensions/Blazorise.Video/Video.razor.cs#L73, and
• https://github.com/Megabit/Blazorise/blob/master/Source/Extensions/Blazorise.Video/VideoJSOptions.cs

We basically need to look everywhere where we have a new object for serializing to JSON and implement a new serialization class.

• https://github.com/Megabit/Blazorise/blob/master/Source/Extensions/Blazorise.PdfViewer/PdfViewer.razor.cs#L112
• https://github.com/Megabit/Blazorise/blob/master/Source/Extensions/Blazorise.PdfViewer/PdfViewer.razor.cs#L112
• etc.

Oh, yeah. You mean making the object that goes to js a strong type... I agree with that.

But I don't see a reason why to include the JsonPropertyName attribute - as discussed above. I would do it only for those properties that require something else than the default camelCase...

Also maybe records instead of class to make it more condensed? Or at least use require keyword to force all the important stuff to be declared..? But that's probably for a different discussion or pr...

So what is left here? The JsOptions for tooltip?

We want this make sure everything is handled properly. So all file must have JsonPropertyName.

Tooltip also need to have a new object.

As for what kind of. Stick with the class. As we have it for Video options.

I think Blazor is always serializing to Camelcase.

• https://github.com/dotnet/aspnetcore/blob/b7c8cf7506338b9cd5c4960bd99b03d190c3c805/src/Components/Shared/src/JsonSerializerOptionsProvider.cs#L12
• https://github.com/search?q=repo%3Adotnet%2Faspnetcore%20JsonSerializerOptionsProvider&type=code

Also, I found this comment from a Blazor team member saying that they don't have plans to change it as it could affect Blazor itself. dotnet/aspnetcore#38144

So we might not need to do this at all.

@stsrki But that's precisely what @tesar-tech was saying. There's currently no way to configure the options globally. I personally was under the impression it was, since it was implied so before.

I'd still take concrete objects over anonymous objects as an improvement to the code base.

@stsrki But that's precisely what @tesar-tech was saying. There's currently no way to configure the options globally. I personally was under the impression it was, since it was implied so before.

I was also under such an impression. But I never tried it in the past.

I'd still take concrete objects over anonymous objects as an improvement to the code base.

Agree. At least make concrete objects even though we might not need to have JsonPropertyName attribute.