A minimal Plug to validate input path/query params in declarative way on your routers
2 Likes
Instead of returning {:error, reason} or other, I think you should return {:error, reason} or {:ok, value}. Any reason why you’ve decided to avoid the common :ok/:error pattern?
3 Likes
I know {:error, reason} is the idiom but since the response from the validator is handled on the library I didn’t think it was important to return {:ok, value} on success.
Having said that, I have no objection to changing the structure as you offer.
I don’t understand… Your validator can return any value, right? Not only the given argument. How would you distinguish the error {:error, x} from the value {:error, x} if you’re not using the {:ok, value} comvention?
3 Likes
I can’t think of a use case in which a validator returns {:error, value} as a valid value 
Again I’m not against returning {:ok, value} but right now I don’t see any reason to change the code.
For what I can understand and tried, this Plug doesn’t work in Phoenix, or am I mistaken?
So I was indeed mistaken, well at least in part… We cannot follow the docs to the letter, because the code will not compile, but it’s possible to make it work, as I describe in this other post: Phoenix Framework: Validate route parameter in the router
