emphasizes that errors in the changeset are data, and hence are being put in values which then gets shown to the end user (~ 4xx http status codes). And errors in :errors are like exceptions (~ 5xx http status codes) which should be dealt with by the developer.
It depends on where you are in the book. There are instances where we turn changesets into GraphQL errors, and there are spots later in the same chapter where we explore using “errors as data”. The def call you show from the book like it’s from the “errors as data” bit.
It is not a typo. My guess is that you are in page 128 in the current beta. If you followed the book, your mutation by now should return an object
object :menu_item_result do
field :menu_item, :menu_item
field :errors, list_of(:input_error)
end
The errors field above is the value: %{errors: transform_errors(changeset)},
The resolution struct itself has two keys: :value and :errors. The confusing part is that the key :errors is the same name as the field but other than that they serve a different purpose. Had the :errors key of the resolution struct been left with its content, the errors would buble up and you would had a return like