Try to implement two step validation: local and remote...

[paluh]

@MonoidMusician asked about "two step validation":

• @paluh: What do you mean by "sync and async errors"?
• @MonoidMusician: if one part of the validation has to check something with the server but the other is a quick “is this syntax right”, it seems like those could be validated independently or something ...

Let's try to implement this scenario using Input.Interpret - I'm not sure if it is possible though:

• @paluh: One "dirty" solution to your "two step" validation could be:
  • build form using Polyform.Input.Interpret primitives + your own *F validation types
  • construct first interpretation which runs in browser and skips remote validation "somehow"
  • construct second interpretation which runs also remote calls

[thomashoneyman]

@paluh This is also necessary for my use case :) 👍

[paluh]

EDIT: this example is outdated!

EDIT: Below are another proposition which should be considered first I think...

@MonoidMusician, @thomashoneyman: Does this version of validation involving Run solve your use case?

data EmailUsage = Used | NotUsed | Unknown

data EmailInUseF a = EmailInUseF String (EmailUsage → a)
derive instance functorEmailInUseF ∷ Functor EmailInUseF

type EmailInUse = Free EmailInUseF

email addr = liftF (EmailInUseF addr id)

checkEmail' r@{ email: addr } = do
  inUse ← email addr
  pure $ case inUse of
    -- | XXX:
    -- | Possibly we could add this information (that validation result is `Unkown`)
    -- | to our form representation
    -- | or field value representation (and add throbber etc. when rendering)
    -- | To be honest this check should be executed
    -- | on email field level... I have to probably rewrite this
    -- | example with field level validation too ;-)
    Unknown → pure r
    NotUsed → pure r
    Used → Invalid (errorForm "Email already in use")

signupForm' ∷ Component EmailInUse Form Http.Query { password ∷ String, email ∷ String }
signupForm'
  = ({email: _, password1: _, password2: _}
  <$> emailForm
  <*> (passwordForm (_{ name = "password1" }))
  <*> (passwordForm (_{ name = "password2" })))
  >>> (hoistMV checkEmail' *> hoistV checkPasswords)
 where
  checkPasswords r@{email, password1, password2 } =
    if password1 == password2
      then pure { password: password1, email }
      else Invalid (errorForm "Passwords don't match")

interpretLocal (EmailInUseF email k) =
  pure $ k Unknown
interpretRemote (EmailInUseF email k) = do
  -- | let pretend that we are using email and get some response from API
  (r ∷ AffjaxResponse String) ← affjax $ defaultRequest { url = "http://google.com", method = Left GET }
  -- | Process response and inform about results ;-)
  pure $ k Used


validateSignupLocal
  ∷ forall m
  . MonadRec m
  ⇒ Http.Query
  → m
    (V Form
      { password :: String
      , email :: String
      })
validateSignupLocal query = foldFree interpretLocal $ runValidation signupForm' query

validateSignupRemote
  ∷ ∀ eff
  . Http.Query
  → Aff ( ajax :: AJAX | eff ) (V Form { password :: String , email :: String })
validateSignupRemote query = foldFree interpretRemote $ runValidation signupForm' query

[paluh]

EDIT: this example is outdated

As I've pointed above in the comment I want to provide another alternative solution which would allow us to keep information about validation state so we can for example inform user that validation is still running etc. but providing also quick feedback with all already known (local) errors.

This is going to be a bit more involved. When we want to keep information about validation status of a field validation we have a least two options:

• We can keep it on the form level - this restricts our solution to given form representation and we are not able to reuse this field if we want to use it in different forms (for example I'm using two types of forms in my projects - one is just a Tuple [] [] and other allows me to use records and it is: Join (->) r).

• We can add information about validation status to the field value - I really want to emphasize here that form value is (usually) build from underling field value BUT it is not mandatory that they are the same values.

I prefer second approach.

I think that all type signatures are optional but I've included some of them for clarity. So here it goes:

-- | We can use this `Boolean` value
-- | when rendering a field to show a throbber etc.
type CheckedEmailValue = Tuple Boolean String

-- | We restrict ourselfs to HTTP input here
-- | but this error row can be easily parametrized
-- | and field could be reused for different types
-- | of inputs (this strategy is used for fields
-- | defined in `Field.Html5`)
type CheckedEmailErr = Variant (Http.StringErr (isUsed ∷ String))

-- | We could use helpers like `Html5.TextInputBase` or functions
-- | from `Field.Input`or `Input.Http` here but I want to show
-- | that there is no "magic" behind the curtain.
-- | Just plain records.
-- | Of course we could add additional `attrs` parameter to this record
-- | like in `Field.Html5`).
type CheckedEmailInput =
  { name ∷ String
  , value ∷ Either CheckedEmailErr CheckedEmailValue
  }

-- | It is also worth to mention here again that
-- | `value` attribute from our field
-- | DOES NOT HAVE TO BE THE SAME as
-- | value build by a form containing it.
-- | So even though this field contains `Tuple Boolean String`
-- | as value on the form level we are going to have just `String`.
-- |
-- | I've just extended helper function and
-- | added `Polyform.Component.fromFieldCoerce`
-- | to help build a form with such a difference
-- | on "field-form" level.
checkedEmailInputValidation
  ∷ forall err.
  Field.Validation
    EmailInUse
    CheckedEmailErr
    String
    (Tuple Boolean String)
checkedEmailInputValidation = Field.hoistMEither $ \addr → do
  isUsed ← email addr
  pure $ case isUsed of
    Unknown → pure (Tuple false addr)
    NotUsed → pure (Tuple true addr)
    -- | Default validators use `Variant` error representation.
    -- | If we want to easily compose with them
    -- | we should use it too.
    Used → Left (inj (SProxy ∷ SProxy "isUsed") addr)

-- | Let's extend our validator so it works on `Http.Value ~ (Array (Maybe String)`.
-- | Basically we are preprocessing `Value` into single `String`.
checkedEmailInputValidationHttp
  ∷ ∀ err.
   Field.Validation
    EmailInUse
     -- | All errors which could happend during our validation from `Value`
     -- | to our final value.
     CheckedEmailErr
     Http.Value
     (Tuple Boolean String)
checkedEmailInputValidationHttp
  = Field.hoistPure catMaybes
  >>> Field.required
  >>> Field.scalar
  -- | This composition chain stops
  -- | on the first encountered error.
  -- | If preceding validations fail
  -- | we won't run the last one.
  -- |
  -- | As a side note we could consider
  -- | also aggregating scenario
  -- | like in `Alt` instance for `Except`.
  -- | Currently there is no `Alt` instance
  -- | for `Field.Validation` BUT I want to provide
  -- | at least two instances `AltAcc` (which
  -- | accumulates errors and would return `Left`
  -- | when there is at least one error)  and
  -- | `AltRight` (standard approach - return first `Right`
  -- | if encountered).
  >>> checkedEmailInputValidation

-- | Now we are fully armed - we have:
-- |   - field representation
-- |   - field validation
-- |   - form representation
checkedEmailForm emailField =
  Http.fromFieldCoerce
    coerce
    (fieldForm CheckedEmailInput)
    emailField
    checkedEmailInputValidationHttp
 where
  -- | Our final validation result on the form level
  -- | should be just email without information about
  -- | validation progress ;-)
  coerce (Tuple _ v) = v

-- | All stuff below is nearly the same as in above example.
-- | We are just not using `emailCheck` validation
-- | on the form level any more.
data EmailUsage = Used | NotUsed | Unknown

data EmailInUseF a = EmailInUseF String (EmailUsage → a)
derive instance functorEmailInUseF ∷ Functor EmailInUseF

type EmailInUse = Free EmailInUseF

email addr = liftF (EmailInUseF addr id)

interpretLocal (EmailInUseF email k) =
  pure $ k Unknown
interpretRemote (EmailInUseF email k) = do
  -- | let pretend that we are using email and get some response from API
  (r ∷ AffjaxResponse String) ← affjax $ defaultRequest { url = "http://google.com", method = Left GET }
  -- | Process response and inform about results ;-)
  pure $ k Used

signupForm'' ∷ Component EmailInUse Form Http.Query { password ∷ String, email ∷ String }
signupForm''
  = ({email: _, password1: _, password2: _}
  <$> checkedEmailForm { name: "email", value: Right (Tuple false "") }
  <*> (passwordForm (_{ name = "password1" }))
  <*> (passwordForm (_{ name = "password2" })))
  >>> hoistV checkPasswords
 where
  checkPasswords r@{email, password1, password2 } =
    if password1 == password2
      then pure { password: password1, email }
      else Invalid (errorForm "Passwords don't match")

validateSignupLocal'
  ∷ forall m
  . MonadRec m
  ⇒ Http.Query
  → m (V Form {password :: String, email :: String})
validateSignupLocal' query = foldFree interpretLocal $ runValidation signupForm'' query

validateSignupRemote'
  ∷ ∀ eff
  . Http.Query
  → Aff ( ajax :: AJAX | eff ) (V Form { password :: String , email :: String })
validateSignupRemote' query = foldFree interpretRemote $ runValidation signupForm'' query

[paluh]

@thomashoneyman, @MonoidMusician
I want to ask you:
Do yo think that provided solutions would work for you or do you feel that Run based solutions are not the way to go at all?
If we agree that Run based interpretation can be a base for solution of "local and remote" validation problem I want to ask: Do you think that I should provide special type and modules to handling these kind of scenario which involves "partial" validation? I mean something like this type (plus whole stuff around):

data V = Valid e v | Invalid e | Unknown e

In such a case our interpretation or other validation steps could "not finish" or "skip" by returning Unknown. Of course there will be easy "lift" from current V into this extended type but it this new type would cost me to clone a lot of code from Form.Validation anyway.

What do you think?

[thomashoneyman]

@paluh Sorry to be getting back to you so late. It's a heavy week at work!

I'm not particularly familiar with Run so I can't comment on whether it should be used or not. I've been digging into the code a bit and this looks extremely promising -- I do still plan to build a minimal example using Halogen to see how that pans out and I'm sure I'll have a few questions for you there.

I'm not sure that the "not finish" or "skip" possibilities are necessary, especially if it'll cost you a lot of duplication. Your monadic validation up there also looks good to me.

[paluh]

Hi @thomashoneyman,

CC: @MonoidMusician

I'm not particularly familiar with Run

Run is AWSOME - check it out! ;-)

I'm not sure that the "not finish" or "skip" possibilities are necessary, especially if it'll cost you a lot of duplication. Your monadic validation up there also looks good to me.

I think that thanks to this discussion (and our overall github discussions) I'm going to... simplify library design which would probably simplify implementation of such scenarios like "partial" validation:

• I'm going to drop dedicated Field.Validation and provide Form.Validation.Monad (and I probably move entire directory outside - maybe to separate lib??).
• I'm going to use V instead of Either in my fields.
• I'm going to prove this design on Input.Http and Input.Foreign and Input.Interpret.

If this prototyping succeed it should be easy to represent nested forms validation AND add information like "unfinished validation" directly into e monoid in field/form... So I hope I will hit this two birds at once!

I'm going to inform you about the results (probably next two days) and provide new examples for above scenarios.

[thomashoneyman]

@paluh Keep me in the loop! I was hoping to build a simple form in Halogen using Polyform tomorrow, but if I should wait for these changes I can do so.

[paluh]

@thomashoneyman
I've pushed new release and updated a README.

I'm going to implement some utils for Foreign validation as I need them in my project too. I think that you are interested in JSON validation and this would help you - Am I right?

I'm going also adapt my current project which uses this lib to this changes.

After these steps I will provide some feedback and we will know if we can treat current state of this library API as stable (I hope so - I've some code which relies on this lib and these movements cost a lot of refactoring ;-)).

[thomashoneyman]

I certainly understand that feeling! Even so, it's better to make these movements now rather than later when even more depends on the code. I'll be working through a small sample in an hour.