Precise typing of embeds

[shutangyu]

Currently strukt typing embeds_one :foo, Foo's type as Foo.t(), embeds_many :foos, Foo as [Foo.t()]:

strukt/lib/typespec.ex

Lines 72 to 77 in 2b6c643

	|> Enum.map(fn
	{name, %{type: :embeds_one, value_type: type}} ->
	{name, compose_call(type, :t, [])}
	{name, %{type: :embeds_many, value_type: type}} ->
	{name, List.wrap(compose_call(type, :t, []))}

it couldn't handle situations like

• :foo field could be null which type should be Foo.t() | nil,
• :foos could be nil, but element couldn't: [Foo.t()] | nil
• :foos could be nil, element's could be nil too: nil | [Foo.t() | nil]

any idea for handle these cases?

[bitwalker]

We can probably generate a type like Foo.t() | nil in cases where the field is known to be optional easily enough. An embeds_many should always be a list though, i.e. nil is violating the contract of the schema. If we're getting nil in those fields as a result of something strukt is doing, then we should certainly fix that (i.e. if we're generating default values which are nil rather than []. Likewise, embeds_many with a nil element doesn't make sense, as you either have an empty list, or a non-empty list of valid records, not a list of possibly-invalid records. As far as I know, it isn't possible to express a schema that permits nil records in an embeds_many field anyway.

Do you have some specific examples for the embeds_many cases? That may help demonstrate the issue there better and give me some ideas on whether or not its something we can address.

[shutangyu]

thank you for your rapid reply!
The embeds_many case is derived by thinking the embeds_one case, so I don't have example for it. but sth similar is graphql's combination of list and non-null https://graphql.org/learn/schema/#lists-and-non-null