More friendly explanation for :malli.core/invalid-type

[vemv]

Hi!

The following:

(malli.error/humanize
 (malli.core/explain [:sequential :string] #{"a"}))

returns "invalid-type". That could be improved in a couple ways:

• it could say expected :sequential, got :set
  • i.e. mention the two specific types involved in the type mismatch.
• additionally, or instead (for agility's sake), say there was a type mismatch for this value
  • while it might look like simply like a verbose rewording of "invalid type", it actually would make it evident that the value is wrong, not the schema itself (which is what I mistakenly believed while debugging this).

wdyt?

Thanks - V

[ikitommi]

I think the error should be improved here. To get a schema type for the value, we would have to run inferring on it. This would make the humanize orders of magnitude slower than it is now and make the bundle size bigger as malli.error would depend on malli.provider.

Some options here:

1. just say "expected :sequential", PR welcome

2. make the inferrer 1000x faster (planning on doing that, at some point)

3. use the options, Luke:

(me/humanize
 (m/explain [:sequential :string] #{"a"})
  {:errors {::m/invalid-type {:error/fn malli.provider/what-you-asked}}})

[vemv]

Thank you!

just say "expected :sequential",

This SGTM if that means a nice default for everyone 👍

(FYI I don't have the capacity these days to create many PRs)

This would make the humanize orders of magnitude slower

I respect this constraint, however one can see that there are at least two types of use cases:

• End-user-facing errors
  • performance has to be optimal here - APIs can have stringent requirements
• Developer-oriented errors
  • Clojure developers can also be consumers of humanized errors (Spec Expound is a good example)
  • this sort of humanized explanation normally will ultimately come from instrumentation, a :pre, assertion, etc, so performance simply doesn't matter here

It would seem wise to not couple the performance characteristics of both use cases.

Perhaps a separate ns e.g. malli.explain-helpers.dev could be provided? With that naming it would be pretty clear that it's not meant for production usage.

[arichiardi]

use the options, Luke:

(me/humanize
(m/explain [:sequential :string] #{"a"})
{:errors {::m/invalid-type {:error/fn malli.provider/what-you-asked}}})

Newbie (we just started using malli here) - I have run into this and I wonder if you the solution there would be to use any of the functions within that namespace (however, many don't have a matching arity).

[vemv]

Additional data point - I also see this behavior almost daily while developing Reitit apps and it can be fairly frustrating at times!

[neuhalje]

(me/humanize
(m/explain [:sequential :string] #{"a"})
{:errors {::m/invalid-type {:error/fn malli.provider/what-you-asked}}})

Hi @ikitommi, that confused me even more. malli.provider/what-you-asked is not a fn in malli. Do you maybe have a good working example for this?

[ikitommi]

@neuhalje please loook malli.error for example functions.