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

Add validation functions for textArea and dropdown #82

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

srid
Copy link
Contributor

@srid srid commented Jul 30, 2019

The current validationInput only works with inputElement. This PR creates two similar functions to work with textArea and dropdown.

Unlike the other two input types, dropdown input's values can be of arbitrary type, v, instead of necessarily being Text. To accommodate this ValidationConfig type now takes an extra type parameter, v, that specifies this type. For validationInput and validationTextArea this is Text, but for validationDropdown it is the user that will provide this type.

{ _validationConfig_feedback = const blank
, _validationConfig_errorText = id
, _validationConfig_validation = const $ toDynValidation $ pure $ Left "Validation not configured"
, _validationConfig_validationM = Nothing
, _validationConfig_initialAttributes = mempty
, _validationConfig_validAttributes = mempty
, _validationConfig_invalidAttributes = mempty
, _validationConfig_initialValue = ""
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe require Monoid v here and add a second mkBaseValidationConfig or something without that constraint that takes an argument.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay. Does it make sense to deprecate defValidationConfig in the process? Because I wonder about the value of having two functions (with non-similar names to boot).

Copy link
Collaborator

@3noch 3noch Jul 31, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mkValidationConfig seems like a better name since "base" is not in the type's name. You can't deprecate the argument-taking one because v may not be monoidal. (Unless you expect people to construct from the record directly...)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can't deprecate the argument-taking one

Yea, but I meant: deprecate the other one (one that has the Monoid constraint).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't that the one that @eskimor is proposing you add? Maybe I missed something.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think not having to provide an argument for the common case is useful and would make this change less breaking (maybe not breaking at all). So I don't think we need to deprecate anything.

{ _validationDropdown_input :: Dropdown t (Maybe a)
, _validationDropdown_value :: DynValidation t e a
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need validation for a dropdown? Shouldn't we just only offer options that are valid?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eskimor One of the items in the dropbox can be "Select an item" (which would be the default selection). If the user has not in fact selected one of the other items, we would want to display a validation error.

The "Select an item" thing would be Nothing, and the other items Just a. So we would just use the validateJust function here.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. Thanks!

@srid srid force-pushed the sr-more-validation-inputs branch 2 times, most recently from a5c5482 to c82d0e6 Compare August 1, 2019 23:51
@srid srid changed the base branch from db-backdrop-modal-widget-impure-validation-haveibeenpwned-raw-task-big-update to develop August 1, 2019 23:51
@srid srid force-pushed the sr-more-validation-inputs branch from c82d0e6 to 5b334cd Compare August 1, 2019 23:52
@srid
Copy link
Contributor Author

srid commented Aug 1, 2019

This PR now targets the develop branch.

To compensate for the fact that Dropdown has no HasDomEvent instance

(cherry picked from commit fbe9e2b)
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

Successfully merging this pull request may close these issues.

3 participants