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 ***@***.***> 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 <#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 ***@***.***> 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 <#14 (comment)>, 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