Closed adamransom closed 3 years ago
@adamransom should this be a coercible string?
Well, a string is a string I guess 😄 but I see the Params
namespace as a place for all things you would usually expect to receive from HTTP parameters, String
being one of them.
Though perhaps it is purely meant for coercion of things from params, in which case I suppose my work-around is what's intended?
But yeah, this issue is mainly just an ergonomics thing when using default: :params
.
@adamransom I think it should be added as Types::Params::String = Types::Nominal::String
because param values are either string, array or hash and we don't want to accidentely coerce an array or a hash into a string. Does this make sense?
Yeah, definitely agree with that, and that's what I use as a workaround for now.
Though I suppose if we go down this route, we'd need to add ones for array and hash too, in order to be consistent with Params
having everything we'd expect from HTTP params.
@adamransom good point. This also should be documented so that people don't expect any type of coercion.
Right, I guess the short description is:
Params
contains every type you would expect to receive via HTTP params, coercing where it makes sense. Currently, everything is coerced exceptParams::String
,Params::Array
andParams::Hash
.
Would we want to use Nominal
or Strict
as the types behind Params::String
, Params::Array
and Params::Hash
though? The params type raise if they can't be coerced, so I'd imagine the expectation is to raise if the type isn't an array, for example.
Using nominal type won't work, see https://github.com/dry-rb/dry-types/pull/394 But I think strict types should work 🤔
When including types using
params
as the defaultfor use in form objects for example, it would be nice to be able to define an attribute in a struct as being a regular string
Currently this doesn't work and you instead need to define the
name
attribute withTypes::Nominal::String
which just feels a bit off.I currently work around this by just defining my own
String
inside theTypes
module, but I was just wondering whether it wouldn't make sense inside theParams
namespace.