You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Iron provides several methods to refine a value at runtime (e.g refineEither, refineValidation)... These methods use a String as error containing the message field of the constraint (e.g "Should be positive").
While it make things simple for a beginer and small demos, it does not make things ergonomic in common cases.
createUser("Iltotore", "") //Left("!(Should only contain whitespaces)")
createUser("", "Raphaël FROMENTIN") //Left("!(Should only contain whitespaces)")
Different errors, same message. Note that you cannot solve this problem by using DescribedAs since both name and aka store the same type: a Username (assuming they have the same properties in this example, making a specific AKA type would be overkill).
But they might not be useful in several use cases:
valalternativeNames=List("totore", "Il_totore", "", "rfromentin")
.refineAllEither[Not[Blank]] ////Left("!(Should only contain whitespaces)")
It would have been useful to know which value did not pass.
Solution
As @vbergeron suggested, errors could be more structured than a plain String. I think a case class containing the value and the error message is a good starting point:
caseclassInvalidValue[A](value: A, message: String)
And since the field problem (see the first example) is very common an Option[String] field looks good to me:
I am not in favor of changing refineEither, refineUnsafe etc. (at least not before 3.0) in order to preserve retrocompatibility but I think the cost is affordable for all variants since:
They are recent (since 2.5.0)
They are not much useful in their current state
Then, example 2 would become:
valalternativeNames=List("totore", "Il_totore", "", "rfromentin")
.refineAllEither[Not[Blank]] ////Left(InvalidValue("", "!(Should only contain whitespaces)"))
Such error structure would also be used for future validation variants like refineAllValidation:
List("", "totore", "", "Il_totore").refineAllValidation[Not[Blank]]
/*Failure(NonEmptyChunk( InvalidValue(" ", "!(Should only contain whitespaces"), InvalidValue("", "!(Should only contain whitespaces")))*/
What do you think of such system?
Is there a better approach?
Is compatiblity break with refineAllEither etc. affordable?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Iron provides several methods to refine a value at runtime (e.g
refineEither
,refineValidation
)... These methods use aString
as error containing themessage
field of the constraint (e.g "Should be positive").While it make things simple for a beginer and small demos, it does not make things ergonomic in common cases.
Use cases
Example 1: different fields
Different errors, same message. Note that you cannot solve this problem by using
DescribedAs
since bothname
andaka
store the same type: aUsername
(assuming they have the same properties in this example, making a specificAKA
type would be overkill).Instead, such case often looks like:
One might also want to include the value in the error message.
Example 2: refining a collection of values
Since 2.5.0, Iron provides utility methods to refine collection of values:
But they might not be useful in several use cases:
It would have been useful to know which value did not pass.
Solution
As @vbergeron suggested, errors could be more structured than a plain
String
. I think a case class containing the value and the error message is a good starting point:And since the field problem (see the first example) is very common an
Option[String]
field looks good to me:I am not in favor of changing
refineEither
,refineUnsafe
etc. (at least not before 3.0) in order to preserve retrocompatibility but I think the cost is affordable forall
variants since:Then, example 2 would become:
Such error structure would also be used for future validation variants like
refineAllValidation
:refineAllEither
etc. affordable?Beta Was this translation helpful? Give feedback.
All reactions