Define all `definitions` as union types
ahultgren opened this issue · 2 comments
Currently object and array definitions
are defined using union types, to enable recursive types. For example:
type Article
= Article ArticleRecord
I'm pondering if it would make sense to make all definitions
a union type. The drawback would be more unnesting, but the advantage would be the ability to declare that a certain primitive has a certain type. For example:
definitions:
Article:
type: object
required:
- articleId
properties:
articleId:
$ref: "#/definitions/ArticleId"
ArticleId:
type: string
Currently such definition serves no purpose at all, but if we were to define ArticleId not as a string but as:
type Article = Article ArticleRecord
type alias ArticleRecord = { articleId : ArticleId }
type ArticleId = ArticleId String
we can suddenly prevent for example a CommentId
or UserId
to be used instead of an ArticleId
(for example in an http request). Also the cost of extra nesting and unnesting is likely very small since it's rare to define primitives as a top-level definition
unless it really should be treated as a type.
@eeue56 I'd be interested in hearing what you think about this. Makes sense?
💭 I'm not sure yet. So far, I've found the best way to use swagger-elm (and json-to-elm) is to provide a "starting point" for decoding things. For example, you might make a HTTP request and return Swagger.Article
, but then in order to use it in your program you need something like Swagger.Article -> Omni.Article
. This is because Omni.Article
can represent things in a way that can't be in Swagger.
So in that world, adding an extra layer like this actually makes it more difficult to use, since you then have to unwrap things a bit more. But perhaps it could be that Swagger
could be better used in a different way, but I need to use swagger-elm a bit more to get a better idea, I think.
Actually, it should be possible to use Swagger for more things than I have used it for so far. I'll play around with a bit this week and get back to you!