Added optional argument / virtual getter to enable polymorphism

[R3dByt3]

Hydro currently does not support inheritance / polymorphism in compontents. During the re-hydration from json it could be possible to declare custom converters in order to deserialize abstract or base types correctly. Since various conventions are possible to achieve this behaviour this commit aims to enable the user of this library to adapt as required.

[R3dByt3]

@kjeske it would be nice if you would find some time to look at this PR with me

[kjeske]

Thank you for the contribution. Could you post an example what this PR exactly solves? Maybe there are some important conventions that should be put into Hydro by default?

[R3dByt3]

Thank you for the contribution. Could you post an example what this PR exactly solves? Maybe there are some important conventions that should be put into Hydro by default?

Imagine the scenario to have an abstract model (maybe bound to the frontend, maybe not). Currently hydro seems to serialize all properties within the component, which is fine by me, but if there are abstract classes being used in lists for example an issue arrises:

public abstract class A
{
  public int SomeProp { get; set; }
}

public class B : A
{
  public int SomeOtherProp { get; set; }
}

public class SomeComponent : HydroComponent
{
  public List<A> SomeObjects { get; set; } = new() { new B { SomeOtherProp = 5 } };
}

NewtonSoft.Json will serialize an Instance of Class B without any issues. But when Hdyro attempts to deserialize this class again, it becomes a bit tricky.

Per default NewtonSoft will just throw an exception, because it cannot create an instance of an abstract type A. Using the type A as non abstract results in loss of 'SomeOtherProp's value or even disturbes deserialzing other types.

A common pattern that I know would be, to add some custom converters, in order to add type flags. These can be used to determine the runtime type. There might be other viable solutions or use cases to modify this (de)-serialization settings. That's why I thought to expose them like this.

What do you think about this?

[kjeske]

A common pattern that I know would be, to add some custom converters, in order to add type flags. These can be used to determine the runtime type. There might be other viable solutions or use cases to modify this (de)-serialization settings. That's why I thought to expose them like this.

What do you think about this?

Ok, I get it. So yes, it sounds like something to extend manually during the startup in AddHydro.

[R3dByt3]

@kjeske sorry for the delay - I have updated the code (hopefully) like you requested

[R3dByt3]

@kjeske bump

[kjeske]

Thanks. Will run some tests shortly.

[kjeske]

Moved to #136

I've added some changes to simplify the settings access, also added the docs.