Value validation handling improvements

[wolfadex]

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]

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]

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.