Support for Primitive (simple) types in Definitions in Swagger Doc

[kahlil29]

The code is written in such a way that we expect the definitions of data in the Definitions HashMap to be complex Arrays/Objects. Consider the following Definition entry in the swagger Doc :

  CustomRoleKeyOrId:
    description: The 20-hexdigit id or the key for a custom role.
    example: revenue-team
    type: string

For this we should probably create a type alias type CustomRoleKeyOrId = Text

[ersran9]

A better approach would be to use a newtype.

On Fri, Feb 22, 2019, 7:43 PM Kahlil Abreu [email protected] wrote:

The code is written in such a way that we expect the definitions of data in the Definitions HashMap to be complex Arrays/Objects. Consider the following Definition entry in the swagger Doc :

CustomRoleKeyOrId: description: The 20-hexdigit id or the key for a custom role. example: revenue-team type: string

For this we should probably create a type alias type CustomRoleKeyOrId = Text

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/byteally/webapi/issues/14, or mute the thread https://github.com/notifications/unsubscribe-auth/ABZvNUVeRceVpVMAS7fCq2elNkVq6fWtks5vP_r5gaJpZM4bJrTE .

[kahlil29]

@ersran9 Okay. I was thinking of extending the current type we store in the State It is currently

data CreateNewType = SumType String [String] [String] | ProductType NewData 

data NewData = NewData
  {
    mName :: String
  , mRecordTypes :: InnerRecords
  }

Or alternatively, when processing the final State value and generating the types, I could add a check for ProductTypes (if they have only record entry in the list then make a newtype instead of data ...

[ersran9]

Only difference between both would be that in the first approach - had someone defined a data type with legitimately one field it will get elaborated as a data X = .. vs newtype X in the second method. But I think legitimate cases of custom data types with one field could be just a newtype and second approach sounds a lot simpler.

On Fri, Feb 22, 2019, 7:57 PM Kahlil Abreu [email protected] wrote:

@ersran9 https://github.com/ersran9 Okay. I was thinking of extending the current type we store in the State It is currently

data CreateNewType = SumType String [String] [String] | ProductType NewData

data NewData = NewData { mName :: String , mRecordTypes :: InnerRecords }

Or alternatively, when processing the final State value and generating the types, I could add a check for ProductTypes (if they have only record entry in the list then make a newtype instead of data ...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/byteally/webapi/issues/14#issuecomment-466414065, or mute the thread https://github.com/notifications/unsubscribe-auth/ABZvNaTvSbxtUNXanzzEWkfJvZfxLczFks5vP_5igaJpZM4bJrTE .

[kahlil29]

The CreateNewType data type was already extended to support TypeAlias (type alias) while fixing #11

So I think what is remaining for this ticket to be solved is to implement the check when parsing the State (and generating types) to convert ProductType values with only one record to NewType.

[kahlil29]

As per the discussion today with @ersran9 We will remove the TypeAlias implementation and instead replace it by the strategy of creating

data SomeNewType = SomeNewType 
  {nTypeRec :: Text}

In the future, the ideal thing to do would be to generate it as newtype SomeNewType = SomeNewType Text

If it's possible (not too expensive and quick), while implementing, we can directly implement the newtype method.

For now we can use the ProductType constructor of CreateNewType to replace TypeAliases