Check roundtrip serialization and deserialization

[deemp]

I implemented a generator of a TypeScript class with other nested classes. Next, I created a test that runs toJSON and fromJSON on an object of that class.

I noticed that the original object usually differs from the object obtained via serialization followed by deserialization.

https://github.com/deemp/Serializable/actions/runs/8650215722/job/23718210999#step:7:62

You can see the generated .ts and JSON files in workflows in my fork.

Alternatively, you can run the GH Action provided in this PR to reproduce my results.

[LabEG]

Sorry, but Haskell is not for me =) Can you create a branch that will contain the generated classes? So that I can run tests with generated models and find the problem.

[deemp]

@LabEG, generated classes and JSONs are available in an artifact https://github.com/deemp/Serializable/actions/runs/8650215722/artifacts/1405866593 for the run https://github.com/deemp/Serializable/actions/runs/8650215722

[LabEG]

@deemp, i check all generated models and have next conclusion: All errors are in complex Union types. The program cannot guess what type it actually needs to use. In simple cases, guessing can be implemented, but in medium and complex cases it will not work. To solve the problem of complex cases you need to override the fromJson method. In this method, implement type guessing as per your business requirements.

    public fromJSON (json: object): this {
        super.fromJSON(json);

        // you logic here

        return this;
    }

I also don’t know any programming languages that implement deserialization of complex union types. If you know any of these, please let me know, I will implement the logic in the same way.

[deemp]

The program cannot guess what type it actually needs to use.

I thought it would use the first matching type in a union.

I also don’t know any programming languages that implement deserialization of complex union types.

I think Haskell aeson can handle this, though I haven't tested it.

[LabEG]

I thought it would use the first matching type in a union.

Yes, that is right.

I think Haskell aeson can handle this, though I haven't tested it.

Google says that there is the same problem, but the solution is different.