New notation for array inputs

[williampollet]

Hey @sunny !!

Thanks for the amazing work :D

I have an idea, regarding inputs and outputs.

What do you think about accepting a new notation when expecting an array of similar objects, such as:

    inputs :orders, type: [Orders]

(Similar to the GraphQL notation)

This way it will be easier to type arrays.

[sunny]

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

[sunny]

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

[sunny]

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

[williampollet]

I'm taking it !

[viralpraxis]

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

[sunny]

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.

[viralpraxis]

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?

[sunny]

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

[viralpraxis]

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

[sunny]

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?

[viralpraxis]

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

[sunny]

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.

[viralpraxis]

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

[viralpraxis]

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

[sunny]

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) }
      }