-
Notifications
You must be signed in to change notification settings - Fork 5
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
Email (downcase) Parser #127
Comments
Oops, just seeing this 😳 ! @inveterateliterate what do you think about passing in an array of symbols to |
That thread really brings us back to parse vs transform huh. If we were to pursue transformation type parsers, are you saying that it could accept an option like By the way, I am starting to think really all the parsers in this gem are transformers? we give it in an input and we do something with that input, usually putting it in another form (date parser, phone parser, float parser, etc) - we don't analyze the structure of the input and return the decomposed parts. Other "parsers" are more "validators" or "sanitizers" e.g., boolean parser (actually this parser both validates an incoming boolean or transforms the outputs of checkboxes in to booleans) Might be worth thinking about that and choosing which one we're doing. This gem could provide both but we might want to do some renaming to be more clear about our intentions. |
@inveterateliterate My SLA is getting better, but it's still pretty awful 😅. Sorry about that! I'm not suggesting to have an In my opinion, validations aren't really suited to this library and seem more appropriately handled at the model or database layers. In terms of the boolean parser, I'm not sure that I would consider the check on allowable classes to be "validating". If the input is already a Let me know if above I'm misinterpreting what you meant by:
|
I don't totally remember why I threw the word validate in there. But it does transform. Checkboxes come in as "0" and "1" - both of which are truthy. The boolean decanter makes an explicit call out for this: https://github.com/LaunchPadLab/decanter/blob/main/lib/decanter/parser/boolean_parser.rb#L10 to coerce those values into expected results from the UX. Either way I think the original discussion of parsing vs transforming still stands. Your suggestion is to be explicit about the concept of "transformation" which I like. We could even add that pattern to things like the boolean decanter. That decanter could just check truthiness but allow for transformations, e.g., transformation: [truthy_option, falsy_option] and we could have things like ['Yes', 'No'] (idk if we'd use it but just extrapolating the concept) |
I could see a case for customizing the accepted If you'd like to incorporate that into the library, would you mind creating a separate issue? I'll close this one for now given that the discussion has extended beyond the scope of the intended request. |
Feature Description
Suggested Solution
I have been foiled too many times by forgetting to downcase emails prior to saving or when comparing on
find
. Thoughts on adding anemail
ordowncase
parser that downcases, and could also do some other fun email regex?the regex bit may be a bit much, although there are examples here as well as a lengthy discussion on the pros and cons / challenges:
https://stackoverflow.com/questions/38611405/email-validation-in-ruby-on-rails
Curious if people have solved this in other ways!
Alternatives Considered / Existing Workarounds
email
input for type validationAdditional Context
In other apps I do have code like:
validates :email, presence: true, uniqueness: { case_sensitive: false }
on models with email fieldsas well as this:
since we did have some mismatch of cases at one time
The text was updated successfully, but these errors were encountered: