nimble_options
nimble_options copied to clipboard
Add validation type to `NimbleOptions.ValidationError`
@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.
Pull Request Test Coverage Report for Build d7df5c28720d1edd68b0d059fcf4569b14733347-PR-134
Details
- 3 of 3 (100.0%) changed or added relevant lines in 1 file are covered.
- 5 unchanged lines in 1 file lost coverage.
- Overall coverage decreased (-1.7%) to 91.753%
| 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 |
š - Coveralls
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_tuplethen 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.
-
After digging into this more I'm not sure how specifying
{:type, _}allows us to not pass the human-readable version of the type tostructured_error_tuple. It makes sense for a type like:integerbut 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. -
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 š