Dry::Struct::Error not showing all errors

I have a Company object like that :

class Company < Dry::Struct
  constructor_type(:strict_with_defaults)

  LegalForms = Types::Strict::String.enum('SA')

  attribute :name,        Types::Strict::String
  attribute :legal_form,  LegalForms

end 

It’s there a way to show ALL types errors ?

When I do :

Company.new

It show only the first type error (name here)

([Company.new] :name is missing in Hash input)

I want something like :

[Company.new] :name is missing in Hash input, :legal_form is missing in Hash input

Hm, structs are not intended for this, you should use dry-validation to validate your data. However, the message could be improved, probably. Can you file an issue to the dry-types repo on github? I’d have a look this weekend.

Hi, thank you for your answer @flash-gordon and sorry if this is “noobs” questions.

The thing that I don’t understand, it’s why do we have to separate the validation ? Is this not an anti-pattern ? With separated validation, we could have invalid object ?

When something is possible, it means it’s going to happen.

You’re right, @xero88, a validation result object can be invalid, but this is actually the purpose of these objects, they’re dedicated to modelling a validation result, valid or otherwise.

In this way, they actually allow us to avoid this anti-pattern, because when we have an invalid validation result, we won’t attempt to create a domain model object with that invalid data. (domain model objects are the kind that solnic was suggesting should never be created with invalid state)

Ok, I understand what you mean here.
But the dry-validation Schema must be in the object Company then ? or no ?

The schema should be separate from the domain object, and it should be as close to the “edge” of your application as possible, i.e. as close to the place where you’re accepting user/foreign input. In typical web apps, this means being close to the form. You’ll want to run the form submission through the schema before doing anything else with that data (e.g. choosing to create a domain model from it or not).