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

Use typeclasses for decoding input types #5

Open
KacperFKorban opened this issue Mar 3, 2024 · 3 comments
Open

Use typeclasses for decoding input types #5

KacperFKorban opened this issue Mar 3, 2024 · 3 comments

Comments

@KacperFKorban
Copy link
Owner

Add decoders for fields, so that we don't have to hardcode generation logic in the macro code

  • This is interesting because it would be nice to be able to add some sort of validation to custom types
  • A default derivation should be provided for the most common use case
  • But what should be the function in the type class? String -> Either[String, A] sounds good, but we want to support more than just text fields 🤔
    So the type class should provide both the type of the field and the decoder, but how to make it type safe?
@KacperFKorban
Copy link
Owner Author

Now that I think about it. Returning Either[String, ...] doesn't make that much sense. There is no good feedback loop in the form. It would only be able to return the error when submitting the form, so it is no different than verifying the input in the function implementation. Unless of course, we compile the type classes separately to js functions using Scala.js and attach them to the generated site. I don't have any good ideas on how to do that though. (Other than running scala-cli during site generation, which seems like a HUGE hack)

@KacperFKorban
Copy link
Owner Author

A decent idea is to define a decoder as

trait Decoder[-I, O]:
  def decide(I: I): O

Then we can summon Decoder[Nothing, T] in the macro generated code. (If we can manage to get that to work) Or maybe we can make I a type member instead.

Then based on the I we can figure out the field type, probably.

Not sure how to handle dropdowns with this encoding though. Maybe the I type should only ever be an internal InputType? Or maybe just add a field to the type class that defines the input field type?

e.g.

trait Decoder[O]:
  type I <: InputType
  def decide(I: InType[I]): O

(This might have to be on the term level)

@KacperFKorban
Copy link
Owner Author

One implementation detail for implementing this is that the generated code should change the eithers into exceptions, apply the function to the arguments extracted from the eithers and optionally catch the exceptions.

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

1 participant