Email (downcase) Parser

[inveterateliterate]

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]

cc @dianacamacho

[dianacamacho]

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

[chawes13]

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

[inveterateliterate]

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]

@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]

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]

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.