How to convert a typed definition to a typedstruct?

Looks like TypedStruct supports all typespec in Elixir. If that’s true then depending on your needs you can use a map notation or reference to other type - just like you do with String.t(). I do not see a problem if referenced module would also use TypedStruct.

I’m also a great fan of TypedStruct (and its cousin TypedEctoSchema).
I would definitely go for defining a User struct.
The reasoning for doing that would be the same as for creating the OrderInfo struct in the first place: Ensuring that mandatory fields are present, and make it clearer what is passed around.
If User is only used in the context of OrderInfo, I would name it accordingly, i.e. OrderInfo.User.

I have to admit that I try to use (typed)structs as often as possible – maybe even too often. But I like the fact that I can be explicit about expectations. I also try to ensure that I pattern match against the expected struct in the function heads that expect structs as input.

Quite interesting !
Do you also add a new function to build the structs? Or do you simply build them manually?

I understand you are advocating for nested module in this use case. Could you please be so kind as to share how your final solution for this would look like?

I’m actually quite undecided on that part. The OOP-developer in me really wants a new-function, as it allows me to have the required fields as required parameters, and then an optional keyword-list or map as the last parameter to fill in optional fields. (It also allows fields to be calculated).

However, lately I am questioning that approach for several reasons: First, the Elixir compiler is quite good at complaining about missing required fields. Second, that last optional parameter taking a map or keyword-list is really not nice to deal. Third, when you have more than three required fields, the approach results in a large number of parameters to the new-function.
Now I am trying to embrace structs as open (non-hiding) data structures. No constructors, and no calculated fields.

“Nested” in the sense of namespace, not in code, though. I really try to keep strictly to one-module per file. I would have the following directory structure:

lib/
  order_info/
    user.ex
  order_info.ex

order_info.ex would then contain something like this:

defmodule OrderInfo do
  use TypedStruct

  typedstruct do
  ..
  end

and, order_info/user.ex:

defmodule OrderInfo.User do
  use TypedStruct

  typedstruct do
  ..
  end

Agreed, just having a few layers of keyword options passed around, with defaults and some having to override others etc., it becomes a huge rabbit hole that’s an extremely easy vector to introduce bugs.

That being said, I’ve been trying to use NimbleOptions in my own hobby work lately and so far it’s serving me pretty well. Bonus points for also serving as kind of a typed schema as well, that was a nice and very welcome surprise.

Yeah, that’s the biggest problem here, and that’s why I started using NimbleOptions and having only a single parameter – the keyword list – which in effect imitates the named function arguments that other languages enjoy (like OCaml). So far I like the result but it’s too early to say because my own hobby OSS work is going at a snail’s pace. Time will tell but tentatively, that library makes things possible and much less annoying.

NimbleOptions looks interesting. I will check that out. Thank you for the pointer.