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

Email (downcase) Parser #127

Closed
inveterateliterate opened this issue Nov 17, 2021 · 7 comments
Closed

Email (downcase) Parser #127

inveterateliterate opened this issue Nov 17, 2021 · 7 comments

Comments

@inveterateliterate
Copy link
Contributor

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 an email or downcase 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

  • custom parser, other model code to support, html email input for type validation

Additional Context

In other apps I do have code like:

validates :email, presence: true, uniqueness: { case_sensitive: false } on models with email fields

as well as this:

def self.find_for_authentication(email)
    find_by('lower(email) = ?', email.try(:downcase))
  end

since we did have some mismatch of cases at one time

@inveterateliterate
Copy link
Contributor Author

cc @dianacamacho

@dianacamacho
Copy link
Contributor

Definitely something i run into often, but maybe @chawes13's suggestion about string parser formats on #113 might be a better fit

@chawes13
Copy link
Contributor

Oops, just seeing this 😳 ! @inveterateliterate what do you think about passing in an array of symbols to StringParser via an option?

@inveterateliterate
Copy link
Contributor Author

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 :email and do the stuff I suggested? That could work but it feels like it would really start to test the single responsibility of something called StringParser and feels like a smell to me.

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.

@chawes13
Copy link
Contributor

@inveterateliterate My SLA is getting better, but it's still pretty awful 😅. Sorry about that!

I'm not suggesting to have an email option. My original suggestion was to modify the StringParser to allow for the composition of string transformation(s) to handle email input (or other strings) as you see fit (e.g., input :email, :string, transformations: [:downcase] or input :special_field, :string, transformations: [:strip, :swapcase]).

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 TrueClass or FalseClass, then it just short circuits the parsing logic (since it's already parsed). That seems more like an optimization than a validation?

Let me know if above I'm misinterpreting what you meant by:

actually this parser both validates an incoming boolean or transforms the outputs of checkboxes in to booleans

@inveterateliterate
Copy link
Contributor Author

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)

@chawes13
Copy link
Contributor

I could see a case for customizing the accepted truthy_ and falsy_options to accommodate additional patterns like /no/i. I think it would be clearer to keep those as first-class options instead of nested within a transformation key.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants