Best way to integrate other input methods, e.g. dropdown menus, into forms?

[bbarker]

I have a form widget that looks like this, which was taken from the metajelo-ui example and modified slightly:

instContactWidg :: FState -> Widget HTML M.InstitutionContact
instContactWidg fstate = do
  query <- D.div' [
      D.div' [D.text "Email"]
    , D.input
      [ P.value $ F.getInput proxies.email1 fstate.form
        -- This will help us avoid hitting the server on every single key press.
      , (F.asyncSetValidate debounceTime proxies.email1 <<< P.unsafeTargetValue) <$> P.onChange
      ]
    , errorDisplay $ F.getError proxies.email1 fstate.form
    , D.div' [D.text "Confirm Email"]
    , D.input
      [ P.value $ F.getInput proxies.email2 fstate.form
      , (F.asyncSetValidate debounceTime proxies.email2 <<< P.unsafeTargetValue) <$> P.onChange
      ]
    , errorDisplay $ F.getError proxies.email2 fstate.form
    , D.div' [D.text "Contact type"]
    , D.menu
      [ P.value $ F.getInput proxies.contactType fstate.form
      , (F.set proxies.contactType <<< P.unsafeTargetValue) <$> P.onChange
      ]
    -- , D.input
    --   [ P.value $ F.getInput proxies.contactType fstate.form
    --   , (F.set proxies.contactType <<< P.unsafeTargetValue) <$> P.onChange
    --   ]
    , errorDisplay $ F.getError proxies.contactType fstate.form
    , D.div' [F.submit <$ D.button [P.onClick] [D.text "Submit"]]
    ]
  res <- F.eval query fstate
  case res of
    Left fstate' -> instContactWidg fstate'
    Right out -> do
      let form = F.unwrapOutputFields out
      pure {emailAddress: form.email1, contactType: form.contactType}
  where
    errorDisplay = maybe mempty (\err -> D.div [P.style {color: "red"}] [D.text $ V.toText err])
    debounceTime = Milliseconds 300.0

The main issue is that when I want to change the text input field defined by:

    -- , D.input
    --   [ P.value $ F.getInput proxies.contactType fstate.form
    --   , (F.set proxies.contactType <<< P.unsafeTargetValue) <$> P.onChange
    --   ]

to a dropdown menu (nonfunctioning as expected):

    , D.menu
      [ P.value $ F.getInput proxies.contactType fstate.form
      , (F.set proxies.contactType <<< P.unsafeTargetValue) <$> P.onChange
      ]

things like F.getInput no longer make sense here.

It isn't clear to me what the best approach would be in general - try to find some way to get e.g. menus to work within a form, or to just have the form not return the complete data type, and integrate it into some regular Concur code to get the full value (in this case of type InstitutionContact).

[ajnsit]

Well, D.menu is just a thin wrapper over the HTML menu element. It is used to add context (right-click) menus to elements, and is only supported in Firefox.

To really get HTML dropdown menus to work (which I think is what you want here), you can use D.select (which wraps the HTML select element), and pass a list of D.option elements. For example -

D.select
      [ P.value $ F.getInput proxies.name fstate.form
      , (F.set proxies.name <<< P.unsafeTargetValue) <$> P.onChange
      ] [ D.option [P.value ""] [D.text "--Please choose an option--"]
        , D.option [P.value "dog"][D.text "Dog"]
        , D.option [P.value "cat"][D.text "Cat"]
        , D.option [P.value "hamster"][D.text "Hamster"]
        , D.option [P.value "parrot"][D.text "Parrot"]
        , D.option [P.value "spider"][D.text "Spider"]
        , D.option [P.value "goldfish"][D.text "Goldfish"]
        ]

[bbarker]

@ajnsit Great, I'm sure most of my issues derived from incorrectly using D.menu, which I realized after the fact, but wasn't sure if it was still be a problem for using F.getInput.

I haven't completely finished integrating my actual example; I'd like to return a non-string value if possible instead of P.value (I'm not sure if there's a polymorphic version of P.value that could be used). Here's my current code, which thanks to PureScript Generic and Concur, is quite slick (just not totally working ...!):

menuChooseTxt :: forall a. Widget HTML a
menuChooseTxt = D.text "--Please choose an option--"

pleaseChooseOption :: forall a. Widget HTML a
pleaseChooseOption = D.option' [menuChooseTxt]

typedDropdownMenu :: forall a s form. BoundedEnum a => IsSymbol s =>
  SProxy s -> FState -> Widget HTML (F.Query form)
typedDropdownMenu proxy fstate = D.select [
  P.value $ F.getInput proxy fstate.form
, (F.set proxy <<< P.unsafeTargetValue) <$> P.onChange
] $ -- pleaseChooseOption :
  allVals <#> (\v -> D.option [P.value v] [D.text $ show v])
  where
    allVals :: Array a
    allVals = upFromIncluding bottom

Or should we just construct a String -> a function backed by Foreign.Object on the fly?

[ajnsit]

Yup, P.value is a thin wrapper around the HTML value attribute which is necessarily a string. I think the best way to go is to create your own class to support options of other types. For example -

class IsOption a where
  toOptionValue :: a -> String
  toOptionLabel :: a -> String
  fromOptionValue :: String -> a

Then you could pass in options of different types, but convert them to string with toOptionValue.

[ajnsit]

Also, I spent a bit of time coming up with a generic select menu widget which could be simply plugged into a form.

menu
  :: forall opt s form e o restF restI inputs fields
   . IsSymbol s
   => IsOption opt
   => BoundedEnum opt
   => Newtype (form Record F.FormField) (Record fields)
   => Cons s (F.FormField e opt o) restF fields
   => Newtype (form Variant F.InputFunction) (Variant inputs)
   => Cons s (F.InputFunction e opt o) restI inputs
   => form Record F.FormField
  -> SProxy s
  -> Widget HTML (F.Query form)
menu form field = D.select
  [ P.defaultValue $ toOptionValue $ F.getInput field form
    , (F.set field <<< fromOptionValue <<< P.unsafeTargetValue) <$> P.onChange
    ]
  (upFromIncluding (bottom :: opt) <#> \opt ->
    D.option [P.value (toOptionValue opt)] [D.text (toOptionLabel opt)])

You could use this in any form. So for example, if the form has a field pet with BoundedEnum values -

menu fstate.form proxies.pet

[bbarker]

@ajnsit Looks good, I will try that now. Maybe once the dust around formless settles a bit this could go into the lib or a contrib lib? Seems quite useful to me, though I don't know how many people would use it in practice.

Also, I did a bit of digging to try to understand formless better as it relates to this example. I see that part of the constraints seem to be FormFieldGet, and if there were a FormFieldSet, that would be the other part:

-- | A type representing a function to produce a value from a record of
-- | form fields given a particular symbol. The result of `view` from
-- | Data.Lens applied with a particular lens to the form.
type FormFieldGet e i o x =
  forall sym form fields t0
   . IsSymbol sym
  => Newtype (form Record FormField) (Record fields)
  => Row.Cons sym (FormField e i o) t0 fields
  => SProxy sym
  -> form Record FormField
  -> x

I was just wondering what role the Newtype class plays here, since we don't seem to be using wrap or unwrap directly, but maybe it is used under the hood?

Thanks again!

[ajnsit]

You are right, the constraints are present because we use functions that use those constraints (F.getInput, and F.set). Basically the Cons constraints are saying that the field we pass is a part of the form and of the right type (the same type as opt). And the Newtype constraints are saying that the form type itself is just a newtype wrapper over a record of the type formless expects, i.e. it can be used as a record of values, or as a sum type with actions setting the various record fields.

The code for the menu itself is pretty simple, but the types complicate it immensely. What's worse is that you can also not leave the type signature out as then Purescript complains about ambiguous types. I am also not happy with the amount of typelevel work that's required to simply use the components provided by formless (when trying to generalise them by putting them in their own functions). I will be looking at ways to improve the situation.

As a compromise, if you specialise the type to an already defined form and field then it becomes exactly as simple as you'd think, since the constraints are already satisfied -

petMenu :: MyForm Record F.FormField -> Widget HTML (F.Query MyForm)
petMenu form = D.select
  [ P.defaultValue $ toOptionValue $ F.getInput proxies.pets form
    , (F.set proxies.pet <<< fromOptionValue <<< P.unsafeTargetValue) <$> P.onChange
    ]
  (upFromIncluding (bottom :: Pets) <#> \opt ->
    D.option [P.value (toOptionValue opt)] [D.text (toOptionLabel opt)])

[bbarker]

OK, that makes sense.

I was playing around with optional types (using Maybe), and went down a bit of a rabbit hole: https://stackoverflow.com/questions/56961130/how-does-one-derive-a-boundedenum-maybe-a-from-a-boundedenum-a

This would be useful to deal with in the case of optional form fields, I think, where one of fields has type Maybe T for some BoundedEnum T.

[bbarker]

And yes, I noticed that the formless type machinery is quite a bit more than vanilla Concur!

[bbarker]

Alright, after another folly of mine, I came up with what seems to be a reasonable solution in the absence of dependent types:

-- | A lawful class to denote Cardinality a << Cardinality Int
class Bounded a <= SmallBounded a

newtype MaybeWrapped a = MaybeWrapped (Maybe a)

derive instance newtypeMaybeWrapped :: Newtype (MaybeWrapped a) _

mayToString :: forall a. Show a => Maybe a -> String
mayToString (Just v) = show v
mayToString Nothing = ""

instance boundedEnumMaybe :: (SmallBounded a, BoundedEnum a)
  => BoundedEnum (MaybeWrapped a) where
    cardinality = Cardinality $ unwrap (cardinality :: Cardinality a) + 1
    toEnum 0 = wrap  Nothing
    toEnum n = wrap $ Just <$> toEnum (n - 1)
    fromEnum Nothing = 0
    fromEnum (Just e) = fromEnum e + 1


instance isOptionMaybeInstitutionContactType
  :: IsOption (Maybe M.InstitutionContactType) where
    toOptionValue = mayToString
    toOptionLabel = mayToString
    fromOptionValue = join <<< hush <<< MR.readInstitutionContactType

instance isOptionMaybeWrappedForward
  :: IsOption (Maybe a) => IsOption (MaybeWrapped a) where
    toOptionValue (MaybeWrapped may) = toOptionValue may
    toOptionLabel (MaybeWrapped may) = toOptionLabel may
    fromOptionValue str = wrap $ (fromOptionValue str :: Maybe a)

Ideally SmallBounded could be added to Data.Enum to avoid much wrapping, but if not, maybe the world's smallest purescript library. Alongside a small library for IsOption.

[ajnsit]

Yup, that looks reasonable. Clever solution with SmallBounded!

[bbarker]

@ajnsit Cool, I created a fork of purescript-enums (and a PR on the upstream repo) to support this. The form seems to be working here. I noticed in your discussion with Thomas Honeyman that the form wasn't behaving as desired; the only thing I've noticed is that I have to click Submit twice - was that what you saw, or something else?

[ajnsit]

@bbarker For me the dropdown changes values to Neither without any user input. It's a bit erratic and I haven't investigated the cause yet.

[bbarker]

Oh, hah, I thought that was the expected behavior in this case, if by Neither you mean Nothing.

Aside from the glitch I sometimes noticed with the submit button (I think it has seemed better today), I actually want to remove it for the particular widget, and have it call F.submit whenever the form changes, and if possible, using the deBounceTime.

Currently I've got something that looks like:

contactForm :: FState -> Widget HTML M.InstitutionContact
contactForm fstate = do
  query <- D.div' [
      D.div' [D.text "Email"]
    , D.input
      [ P.value $ F.getInput proxies.email1 fstate.form
        -- This will help us avoid hitting the server on every single key press.
      , (F.asyncSetValidate debounceTime proxies.email1 <<< P.unsafeTargetValue) <$> P.onChange
      ]
    , errorDisplay $ F.getError proxies.email1 fstate.form
    , D.div' [D.text "Confirm Email"]
    , D.input
      [ P.value $ F.getInput proxies.email2 fstate.form
      , (F.asyncSetValidate debounceTime proxies.email2 <<< P.unsafeTargetValue) <$> P.onChange
      ]
    , errorDisplay $ F.getError proxies.email2 fstate.form
    , D.div' [D.text "Contact type: ", F.submit <$ menu fstate.form proxies.contactType]
    -- , D.div' [ F.submit <$ D.button [P.onClick] [D.text "Submit"]]
    ]
  res <- F.eval query fstate
  case res of
    Left fstate' -> contactForm fstate'
    Right out -> do
      let form = F.unwrapOutputFields out
      pure {emailAddress: form.email1, contactType: form.contactType}
  where
    errorDisplay = maybe mempty (\err -> D.div [P.style {color: "red"}] [D.text $ V.toText err])
    debounceTime = Milliseconds 300.0

This actually works on the menu as shown, but when I try to do F.submit <$ D.input ..., there is a type error:

Error found:
in module Metajelo.Forms
at src/Metajelo/Forms.purs:73:10 - 73:41 (line 73, column 10 - line 73, column 41)

  No type class instance was found for
                                                                  
    Data.Newtype.Newtype (t1 Variant InputFunction)               
                         (Variant                                 
                            ( email1 :: InputFunction t3 String t5
                            | t6                                  
                            )                                     
                         )                                        
                                                                  
  The instance head contains unknown type variables. Consider adding a type annotation.

As a side note, I'm now working on using this as a signal, which is going well so far; next step: I plan to use the signal forms to each emit values that are typically records, all part of a larger record in which they will be injected.

[ajnsit]

This actually works on the menu as shown, but when I try to do F.submit <$ D.input ..., there is a type error:

That's because the input is already returning something, F.asyncSetValidate debounceTime proxies.email1, which is a Query which tells formless to validate the value entered. If you want to do two things, such as validate the input AND submit the form (why would you do that?), then you can use the Formless.andThen combinator to combine two formless queries.

To provide more information about the error message you are getting - F.asyncSetValidate debounceTime proxies.email1 is a very generic Query which has unresolved type variables. The compiler is only able to determine the actual type of the query by observing the place where it is used i.e. passed to eval. When you throw away that query by returning F.submit instead, the compiler isn't able to gain extra type information from the usage site, and throws an ambiguous types error.

As a side note, I'm now working on using this as a signal, which is going well so far; next step: I plan to use the signal forms to each emit values that are typically records, all part of a larger record in which they will be injected.

Signals are nice! I would appreciate feedback on how easy they are to use though, because the usecases for Signals are not very well fleshed out yet. I think they can really simplify a lot of patterns in Concur, and I'm working on a signal based solution to a common problem right now (to update parent state without losing child state).

[bbarker]

This actually works on the menu as shown, but when I try to do F.submit <$ D.input ..., there is a type error:

That's because the input is already returning something, F.asyncSetValidate debounceTime proxies.email1, which is a Query which tells formless to validate the value entered. If you want to do two things, such as validate the input AND submit the form (why would you do that?), then you can use the Formless.andThen combinator to combine two formless queries.

Yes, ideally, it would only be submitted if valid, and really only if all fields are determined to be valid. Hmm, may need to dig into that a bit more. But maybe I'll just leave the submit button on for now and see if I can feed values back to the form so they aren't cleared, which should be a nice experience still.

Signals are nice! I would appreciate feedback on how easy they are to use though, because the usecases for Signals are not very well fleshed out yet. I think they can really simplify a lot of patterns in Concur, and I'm working on a signal based solution to a common problem right now (to update parent state without losing child state).

That sounds pretty similar to what I'm doing, with the parent being the master record, and the children being fields of that record. The metajelo-web repo, written in concur, has widgets for each field, and composes them all together for the entire record, so I can match each widget with each subform, then render the entire record at the end.