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

Type Conversion #384

Closed
michaelstaib opened this issue Dec 3, 2018 · 8 comments
Closed

Type Conversion #384

michaelstaib opened this issue Dec 3, 2018 · 8 comments
Assignees
Labels
🎨 refactoring This issue is about doing refactoring work, like cleaning up the code making existing code better.
Milestone

Comments

@michaelstaib
Copy link
Member

We have currently issues when scalar types are not convertible to a desired type of an input or variable etc. The main reason for that is, that we do not have a clear strategy for that until now. There are currently two or three ways how we tackle this problem.

This PBI shall clarify how we will handle type conversion going forward.

Type converters shall be declared schema wise. This means each schema instance has its own set of converters. Since, also every schema defines its own set of scalars this seems to be natural.

The conversion of values shall be done through the new interface ITypeConversion which can be retrieved through dependency injection.

In order to register a type converter one can register a type conversion delegate with the ITypeConversion interface or register an ITypeConverter as service.

    public interface ITypeConversion
    {
        bool TryConvert(Type from, Type to, object value, out object converted);

        void Register(Type from, Type to, Func<object, object> converter);
    }

    public interface ITypeConverter
    {
        Type From { get; }

        Type To { get; }

        object Convert(object input);
    }
@michaelstaib michaelstaib added this to the 0.7.0 milestone Dec 3, 2018
@michaelstaib michaelstaib added 🎨 refactoring This issue is about doing refactoring work, like cleaning up the code making existing code better. enhancement labels Dec 3, 2018
@michaelstaib michaelstaib self-assigned this Dec 3, 2018
@michaelstaib
Copy link
Member Author

There should be some fallback. So, that event if I just have a schema without any dependency injection setup we should provide like a fallback instance that is always there.

@drowhunter
Copy link
Contributor

whats an example of a scalar not converting to a desired type?

also could this be used to convert "truthy" values to boolean? like 1=true 0=false?

@drowhunter
Copy link
Contributor

drowhunter commented Dec 4, 2018

also is this the same issue raised here #346?

@michaelstaib
Copy link
Member Author

GraphQL has 5 defined scalars (Float, Int, String, ID, and Boolean) those types are bound to .net clr type in Hot Chocolate. So, basically the float is bound to double ... (Boolean is bound to System.Boolean) and so on. The conversion API specifies type conversions from CLR type to CLR type. Basically that a System.Int32 can be converted to a System.String or so on.....

Many of those conversions are already defined by the .net Framework. So, a short can be coerced to an int and so on. But there are custom conversions like DateTimeOffset to DateTime and visa-verse.

@michaelstaib
Copy link
Member Author

also is this the same issue raised here #346?

Yes, I closed 346 since this one has more details.

@michaelstaib
Copy link
Member Author

Since we are opening up the type conversion there should be the possibility to define the scalar type mapping like we can now do with the type conversion.

@michaelstaib
Copy link
Member Author

Since we are opening up the type conversion there should be the possibility to define the scalar type mapping like we can now do with the type conversion.

We will move this one into a separate issue.

@michaelstaib
Copy link
Member Author

This one is now implemented with #387

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🎨 refactoring This issue is about doing refactoring work, like cleaning up the code making existing code better.
Projects
None yet
Development

No branches or pull requests

2 participants