Json serialize, deserialize (dont try to be smart)

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

[severity:It's more difficult to complete my work]
Json can be serialized and deserialized with csharp.system.text.json.
However, the current parser imposes huge risks, as it tries to be smart and does do type conversions automatically.

What's needed, a way to enforce as string, or as number, or to disable the automatic conversions.
Cause when we deal with json we often deal with other code languages who are quite clear on the json standards.
We don't need the c# language to ignore those rules ea "123" is a string 123 is a number.

Whats needed an extension JsonDocument.ParseString($""selectedCar": "{selectedCar}""). RootElement;
Or have it a little bit smarter JsonDocument.ParseString(atributename,stringvalue);

This way existing code could still use the auto conversion, or write as string.
something alike below should be in the C# language

using System;
using System.Text.Json;

public static class JsonDocumentExtensions
{
    public static void SetStringProperty(this JsonDocument document, string propertyName, string propertyValue)
    {
        if (document. RootElement.TryGetProperty(propertyName, out JsonElement propertyElement))
        {
            document. RootElement.Remove(propertyName);
        }

document. RootElement.GetOrAddProperty(propertyName). SetValue(propertyValue);
    }

private static JsonElement GetOrAddProperty(this JsonElement element, string propertyName)
    {
        if (element. TryGetProperty(propertyName, out JsonElement propertyElement))
        {
            return propertyElement;
        }

return element. GetOrAddProperty(propertyName, JsonDocument.Parse($"\"{propertyName}\": \"\""). RootElement.GetProperty(propertyName));
    }

private static JsonElement GetOrAddProperty(this JsonElement element, string propertyName, JsonElement propertyValue)
    {
        element. GetOrAddProperty(propertyName);

var jsonDocument = JsonDocument.Parse(propertyValue.GetRawText());
        var propertyElement = jsonDocument.RootElement.GetProperty(propertyName);

element. RootElement[propertyName] = propertyElement;

return propertyElement;
    }
}

So one can do

if (!string. IsNullOrEmpty(carStatus.SelectedCar))
{
    jsonDocument.RootElement.SetStringProperty("selectedCar", carStatus.SelectedCar);
}

And yes one can say but you have a written extension solution why post this ?... cause it's 2024 the world uses JSON standards !
And if it's as simple as this why not implement it in the language?

---

Original Comments

Feedback Bot on 2/19/2024, 10:55 PM:

(private comment, text removed)

---

Original Solutions

(no solutions)

[eiriktsarpalis]

However, the current parser imposes huge risks, as it tries to be smart and does do type conversions automatically.

What's needed, a way to enforce as string, or as number, or to disable the automatic conversions.

We don't need the c# language to ignore those rules ea "123" is a string 123 is a number.

I'm not sure I follow what the requirement is. You seem to suggest that the parser is automatically converting ints to strings or vice-versa, however that is not the case (the notable exception being JsonNumberHandling which can make conversions when using JsonSerializer (which is a different component)).

It also isn't clear to me how the above relates to the extension methods that you listed. Because JsonDocument/JsonElement are by design immutable DOM types, these also don't compile because you can't set values. If you're looking to achieve that, you should consider using JsonNode instead which does support mutation.

[gregsdennis]

To echo Eirik, JsonElement and JsonDocument are immutable for performance reasons. Specifically, the design is based on taking spans of an underlying string.

In the early designs of my json-everything project, before the nodes API, I was able to create an editable wrapper around elements, but it horribly non-performant. You're welcome to poke around my repo's history to find that, but in the end, elements can't (and shouldn't) be edited. I've since migrated all of my libs to use nodes.

[PGTBoos]

Not sure where the ticket is maintained, i seam to loop in redirections.
The thing was if you give a function " " its a string if you give it a numeric value int/decimal/double etc it's a number.
just because "123" looks alike a number doesn't mean it is a number, for example the next house might be "123A"
this numeric assuming is extreme risky, its solved at my side now, so the topic to me is closed.
And i don't care much, if its faster/slower, it should not cause problems in between systems, hardware is cheap, memory is cheap..
Problems those are expensive can be lethal, dangerous etc.

[eiriktsarpalis]

just because "123" looks alike a number doesn't mean it is a number, for example the next house might be "123A"

Can you share a reproduction? System.Text.Json should never convert strings to numbers in the way that you describe. If it does, then it's likely a bug.