New notation for array inputs about actor HOT 15 OPEN

I'm taking it !

from actor.

That makes a lot of sense! I’d be happy to merge a PR for that 🙏🏻

from actor.

@williampollet Would you be willing to try a patch for this feature using the array: true syntax? 🙏🏻

from actor.

Actually, since now the array syntax for types is used as an "or":

input :age, type: [Integer, Float]

I think it would make more sense to just keep the plural and not have an array:

input :order, type: Order
inputs :orders, type: Order

But perhaps better than the plural which can be a bit too discreet, having it as a new array: true option could make it much more explicit:

input :order, type: Order
input :orders, type: Order, array: true

from actor.

One import disadvantage of array: true it that it won't support type: [T, [T]] input constraints usecase.

In gerenal [T] seems to be more generic ADT-like approach

from actor.

Good point. I think I’d still like the constraints here to be as light as possible and not try to handle all possible types.

One way we could accept more types would be to lean on another constraints/validation gem.

from actor.

One way we could accept more types would be to lean on another constraints/validation gem.

Do you have examples of such gems in mind?

from actor.

I was thinking of dry-validations, or ActiveRecord validations (perhaps with type_validator). But there may be others.

from actor.

I think we could come up with some sort of global configuration option that will switch from our (default) type validation backend to gem-provided backend

dry-rb is more popular, should I try to implement a PoC for this? @sunny

from actor.

I think it would make sense to use dry-validations but I wouldn’t want the gem as a dependency for people who are fine with the simpler current syntax.

I don’t know what the best course of action for that would be. Maybe this means that the glue code between actor and dry-validations lives in a different gem?

from actor.

Yeah, I think we only need to expose some interface so that other gems might use it to provide 3rd-party-gem-backed validation. Also some sort of a global configuration option to select implementation

from actor.

Yeah, makes sense. We could have for example:

• config.validations = :default,
• config.validations = :rails if you include the service_actor-rails gem,
• config.validations = :dry_validation with a new service_actor-dry-validation gem.

To allow that, perhaps the current validations could use more generic before, after & around hooks to avoid having to monkey-patch.

from actor.

To allow that, perhaps the current validations could use more generic before, after & around hooks to avoid having to monkey-patch.

Could you elaborate on that? Seems like I'm missing something here

from actor.

Apart from dry-validations, can we add array: true syntax right now? I'm interested in this feature

from actor.

To allow that, perhaps the current validations could use more generic before, after & around hooks to avoid having to monkey-patch.

I was thinking of a way of “hooking” into actor from outside gems. Using for example before_call :validate_type that could be an interface that can allow outside gems the to add some validation behavior (or any kind of other behavior) and perhaps remove some other behavior (skip_before_call :validate_type). (See also #111).

Not sure this would be the best way to do that, just some thoughts.

Apart from dry-validations, can we add array: true syntax right now? I'm interested in this feature

Sure!

Note that you can do a similar check today with:

input :names,
      type: Array,
      must: {
        be_strings: -> array { array.all?(String) }
      }

from actor.