refactor: introduce new core models

[jonaslagoni]

Description
This PR adds the two basic models discussed in #530

Related issue(s)
Blocked by #530, #654

[magicmatatjahu]

I have some problems with that implementation. I will describe them:

• we should use inline modifiers in the constructors to initialize all properties in the models (I wonder if that type should be also readonly using public readonly modifiers).

• we should use generic for originalInput to define type of input (where possible):

  export class MetaModel<T = any> {
    constructor(
      public name: string,
      public originalInput: T,
    ) {
  }
  
  // we should discuss that generics
  export class StringModel extends MetaModel<string> {}
  export class BooleanModel extends MetaModel<boolean> {}
  // ...etc

• we should avoid long name for props (and also for class names), for example ReferencedModel we can name as RefModel with ref property or for UnionModel the union prop is descriptive:

  export class RefModel extends MetaModel {
    constructor(
      name: string,
      originalInput: T,
      public ref: MetaModel,
    ) {
      super(name, originalInput);
    }
  }
  
  export class UnionModel extends MetaModel {
    constructor(
      name: string,
      originalInput: T,
      public union: MetaModel[] = [],
    ) {
      super(name, originalInput);
    }
  }

  Not only meta models but also constrained models should look like this

• what is the prop type responsible for in ConstrainedMetaModel?

I know these names (for props and for models) were given in the proposal but we can simplify them :)

[jonaslagoni]

• we should use inline modifiers in the constructors to initialize all properties in the models (I wonder if that type should be also readonly using public readonly modifiers).

Why? 🙂

• we should use generic for originalInput to define type of input (where possible):

StringModel does not mean that the input was a string, it could be {type: string}, so I dont quite understand that 😅

we should avoid long name for props (and also for class names), for example ReferencedModel we can name as RefModel with ref property or for UnionModel the union prop is descriptive:

I would probably rather have them completely descriptive, as oftentimes short names lose it's meaning to different users. And when open source, that should be prefered in my opinion 🙂

But I dont think it causes problems for now 🤔 We can change them later with a simple search-replace before releasing.

what is the prop type responsible for in ConstrainedMetaModel?

It is the usage type of a model, i.e. if you want to use a model as a type of a parameter, property, etc, you can simply define it as model.type.

[magicmatatjahu]

Why? 🙂

Because it's a sugar syntax for manual definitions of properties:

export class MetaModel<T = any> {
  constructor(
    public name: string,
    public originalInput: T,
  ) {}
}

// vs

export class MetaModel<T = any> {
  constructor(
    name: string,
    originalInput: T,
  ) {
    this.name = name;
    this.originalInput = originalInput;
  }
}

StringModel does not mean that the input was a string, it could be {type: string}, so I dont quite understand that 😅

You're right, but generic type should be still needed, of course with any as default 👍🏼

I would probably rather have them completely descriptive, as oftentimes short names lose it's meaning to different users. And when open source, that should be prefered in my opinion 🙂

But I dont think it causes problems for now 🤔 We can change them later with a simple search-replace before releasing.

The same arguments were used for version 0.1.0 when we decided to have only one CommonModel :) Really, it makes no sense to have such names. If we have TS then we still have a hint of what type it is then we don't need to add the suffix Model because TS tells us.

It is the usage type of a model, i.e. if you want to use a model as a type of a parameter, property, etc, you can simply define it as model.type.

So then it should be union type not as simple string. We can extend that union, but we should start with some simple type for that.

[jonaslagoni]

The same arguments were used for version 0.1.0 when we decided to have only one CommonModel :) Really, it makes no sense to have such names. If we have TS then we still have a hint of what type it is then we don't need to add the suffix Model because TS tells us.

Alright, I'll change it 🤔

So then it should be union type not as simple string. We can extend that union, but we should start with some simple type for that.

No, it is the "rendered" type. For example for TS the union type property are determined by the constrainer: https://github.com/jonaslagoni/generator-model-sdk/blob/19fc3de0b64424b009282ec0933db7cfca14d9e2/src/generators/typescript/TypeScriptConstrainer.ts#L122

This means that generators and presets if they had to render properties, can simply do:

return `${model.name}: ${model.type}`

Still have to figure out how to do required and optional properties, but this should show the idea of the type property.

If for example, the MetaModel is a UnionModel, the type property would be Type1 | Type2, based on the union MetaModels.

It also serves for other code generators, outside of Modelina, to easier access the type of a model to be used elsewhere.

[magicmatatjahu]

👌🏼 I added some suggestion. Decide what to do with them :)

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[asyncapi-bot]

🎉 This PR is included in version 0.39.9-next.1 🎉

The release is available on:

• npm package (@next dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[asyncapi-bot]

🎉 This PR is included in version 1.0.0-next.23 🎉

The release is available on:

• npm package (@next dist-tag)
• GitHub release

Your semantic-release bot 📦🚀