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

non-guid cursors #6

Open
rkotenko opened this issue Nov 5, 2019 · 7 comments
Open

non-guid cursors #6

rkotenko opened this issue Nov 5, 2019 · 7 comments

Comments

@rkotenko
Copy link

rkotenko commented Nov 5, 2019

It appears that the overloads for ToCursor work correctly. I can choose my id field and have it converted to a base64 string. However, within the ToConnection method, the from methods are set to use the extensions that return Guids, which I do not use. There is no way to indicate that I want to go from cursor to int.

I am not sure how to solve this. Any ideas? I am trying to avoid writing another overload of ToConnection. I also want to avoid a parameter if-check. I am mostly a functional programmer so I prefer my functions to do one thing if I can.

Sidenote: as a functional programmer, C# really kills me. :-D

@rkotenko
Copy link
Author

rkotenko commented Nov 5, 2019

For my purposes, I just changed the method used with Slice in the connection. But I would interested in a more flexible method for C# language learning purposes.

@corstian
Copy link
Owner

corstian commented Nov 6, 2019

Currently I'm thinking several possible solutions:

  1. Implement an overload of the ToConnection method with which one can provide both an encode and decode method.
  2. Implement an convention by which you only have to select the field you intend to use as being cursor, and let the program handle the rest of it.

Number one does not have my preference as it would be quite confusing when reading code which uses the .ToConnection method. For the second approach I would have to check if there's an universal path by which I can convert most basic data types to a base64 representation and back.

@corstian
Copy link
Owner

corstian commented Nov 6, 2019

@corstian
Copy link
Owner

corstian commented Nov 6, 2019

I've also thrown together a proof of concept for the 2nd option, which I will try to move forward with later. Note that this is untested code as of now: https://github.com/corstian/Boerman.GraphQL.Contrib/blob/exp-2/Boerman.GraphQL.Contrib/Query.Extensions.cs#L110

@rkotenko
Copy link
Author

rkotenko commented Nov 7, 2019

I agree that the 2nd option is better. It is cleaner when viewed from outside the library and avoids another overload.

Is ConvertTo meant to be an extension on string which does the "routing" itself?

@corstian
Copy link
Owner

corstian commented Nov 7, 2019

Is ConvertTo meant to be an extension on string which does the "routing" itself?

More or less. See the implementation here: https://github.com/corstian/Boerman.GraphQL.Contrib/blob/exp-2/Boerman.GraphQL.Contrib/Type.Extensions.cs

@rkotenko
Copy link
Author

rkotenko commented Nov 7, 2019

Ahh ok.

Yeah, I like that. Keep the branching logic in its own place. Neat and tidy. :-D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants