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

Value validation handling improvements #82

Open
wolfadex opened this issue Apr 21, 2024 · 2 comments
Open

Value validation handling improvements #82

wolfadex opened this issue Apr 21, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@wolfadex
Copy link
Owner

wolfadex commented Apr 21, 2024

I also see that cases such as Agent and their related validations are not correctly generated also, for example lengths or ranges don't seem to be tested, only that the field exists.

Originally posted by @jamesrweb in #65 (comment)

@wolfadex wolfadex added the enhancement New feature or request label Apr 21, 2024
@wolfadex
Copy link
Owner Author

I'm not certain how much responsibility an http request package should have with validating values, but I'm kinda curious how far this can be taken and still have it be useful. I think my initial hesitation is what should the type of this function look like and how would it feel to use it?


If we take string length as an example, could we generate code like?

changeName :
    { toMsg : Result Error Success -> msg
    , body : Body
    }
    -> Result ClientValidationError (Cmd msg)
changeName config =
    case validateName config.body of
        Ok ->
            Ok (Http.request { ... })

        Err err ->
            Err (ClientValidationError err)

and use it like?

UserClickedSubmitName name ->
    case Api.changeName { toMsg = ServerResponded, body = name } of
        Err err -> Debug.todo "handle invalid name"
        Ok cmd -> ( model, cmd )

  • Can we have both Cmd and Task based requests have equal ease of code gen & use?
  • Is there a better way to structure the generated code?
  • How detailed can we get with validation?
  • Should this be the responsibility of the user (the person using the SDK) and not of the SDK?
  • I'm still interested in doing code gen of forms, likely as a sister tool to this one, using JSON Schema and possibly JSONForms (a sister schema to JSON Schema specifically for forms), would validation make more sense in that tool?
  • What else am I not considering?

I think at this point there are too many questions to know what approach to attempt first/

@jamesrweb
Copy link
Contributor

My 2 cents are that if we are to decode a spec into modules representing that spec, we should handle such validations as defined within the spec. It seems to me that this should be the case for security, validations, proxies and other related concepts to ensure that we truly go from farm to table. Personally, I think that trading off on this would allow unexpected scenarios to occur since the user would have no idea of such cases themselves without knowing the spec inside and out, plus there is no guarantee that the backing service mistrusts the client and so holding the spec as the source of truth during generation would allow impossible states and scenarios to remain impossible.

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

No branches or pull requests

2 participants