Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SignalR returns PascalCase instead of camelCase #71

Open
JeanLoureiro opened this issue Feb 4, 2021 · 6 comments
Open

SignalR returns PascalCase instead of camelCase #71

JeanLoureiro opened this issue Feb 4, 2021 · 6 comments
Assignees
Labels

Comments

@JeanLoureiro
Copy link
Contributor

Hi @larsmichael,

Can we please have the SignalR returning the object in camelCase?
This will make it consistent with the WebAPI format

p7gNkpohOA

Thank you.

cc: @FranzThomsen1089

@larsmichael
Copy link

Apparently this is not natively supported in AP.NET Core 2.2 which is the version we currently use. It can be done using this "hack". However, I am not very fond of this solution because of this comment:

So every time we resolve a contract in the ResolveContract method we have to check the assembly of the type currently resolved and check wether it is SignalR internal. If not, then we can resolve the contract using camel case.

Furthermore, it is very high on the general agenda to update to ASP.NET Core 5.0, where this is natively supported. Hopefully, we can make this upgrade within the coming months.

@goneale
Copy link
Contributor

goneale commented Feb 4, 2021

Hmm... I also returned my own C# POCO's with [JsonProperty("myName")] attribute attached, so I had full control at the other end. Can't this be the approach?

@larsmichael
Copy link

That is a path that i would not like to follow. Generally, we should have as few tech-specific attributes in the domain model objects as possible. Yes, they are already there, but should be kept at a minimum. This approach would require all properties of all domain model objects to be decorated with an attribute. Formatting of JSON-response is a web-concern rather than a domain model concern. Furthermore, we might switch to System.Text.Json instead of Newtonsoft.Json in future versions of the Web API (making the JsonProperty attribute obsolete)

@larsmichael
Copy link

I know that this is mostly a "battle" of who should take the pain of temporarily hacking a solution to this problem: frontend or backend. But in my opinion it must take precedence to keep the generic backend components as clean as possible.

@FranzThomsen1089
Copy link
Collaborator

Clean yes. But consistent as well. It will eventually become camecase this would just be a so that we avoid having many places that would suffer from a breaking change later. Because it will come in both json documents, jobs and time series.

@larsmichael
Copy link

The Web APIs are now updated to ASP.NET 5.0. So the solution is now as described here. Should I add this configuration of SignalR to the VS project templates?

@rihr rihr closed this as completed Nov 4, 2021
@rihr rihr reopened this Nov 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants