Open anthonator opened 2 months ago
Files with Coverage Reduction | New Missed Lines | % | ||
---|---|---|---|---|
lib/nimble_options.ex | 5 | 91.89% | ||
<!-- | Total: | 5 | --> |
Totals | |
---|---|
Change from base Build d42dc90bcfa8a2b6c1f082fb47869e4769f9e9de: | -1.7% |
Covered Lines: | 267 |
Relevant Lines: | 291 |
Yeah I think this is the right path but if we pass {:type, _}
to structured_error_tuple
then we don't need to pass say "integer"
as well, we can move the building of the error message completely to that function and deduce the error from {:type, _}
in that case.
if we pass
{:type, _}
tostructured_error_tuple
then we don't need to pass say"integer"
as well
This is a good idea. I'll do this. Thanks!
I'll continue going down this route. Thank you!
Sorry for not getting back to this sooner!
@whatyouhide a couple things.
1) After digging into this more I'm not sure how specifying {:type, _}
allows us to not pass the human-readable version of the type to structured_error_tuple
. It makes sense for a type like :integer
but not :pos_integer
. We could pattern match on the type to specify the human-readable version but I feel like that adds a ton of code without much benefit. I'm assuming I'm not thinking about this correctly or I'm missing the bigger picture.
2) How should we handle types like {:struct, struct_name}
? I think we should pass {:struct, struct_name}
as the type rather than just :struct
. So the validation would be {:type, {:struct, struct_name}}
. Thoughts?
Instead of building the error message where you validate the type, you can build it (by pattern matching) in structured_error_tuple
. That was my idea by it's been a while so Iām not really sure here anymore š
Thanks for the clarification! That's what I assumed you were referring to. Here is what I wrote in my original question.
We could pattern match on the type to specify the human-readable version but I feel like that adds a ton of code without much benefit.
Would you agree with that?
Yeah this is why I wanted a structured error reason that we could turn into a message later on. Ok, for now let's keep this version passing strings around and I'll see if I can refactor that at some point!
How should we handle types like {:struct, struct_name}
? I think we should pass {:struct, struct_name}
as the type rather than just :struct
. So the validation would be {:type, {:struct, struct_name}}
. Thoughts?
Mh I can't recall if :struct
is a type or if it's {:struct, struct_mod}
. Either way, yeah a separate PR to clean that up if it's weird would be welcome š
@whatyouhide initial attempt at adding failed validation to
NimbleOptions.ValidationError
. Only implemented support for{:type, :integer}
so I can get a sanity check on whether you think I'm on the right path.