enumPrefix / enumSuffix

[igpeev]

Hi,

Observed Setting a default string prefix for models in config.json (like in "modelPrefix": "I",) also affects the generated enums.

Expected Can enums be extracted to a separate schema and generation as it looks awkward in the code to use it like IWeekDay.MONDAY (should be WeekDay.MONDAY) . It's ok to have IWeekDay model/interface, but not IWeekDay enum.

Thanks

        "modelPrefix": {   // <-- existing
            "description": "Prefix for generated model classes. Defaults to empty.",
            "type": "string",
            "default": ""
        },
        "enumPrefix": {   // <-- proposed
            "description": "Prefix for generated enums. Defaults to empty.",
            "type": "string",
            "default": ""
        },

[luisfpg]

The idea of having a prefix is not for I as of interfaces, but to create a sort of namespace when multiple APIs are generated to the same folder. Suppose: Api X, Api Y, Api Z. They could have a common model or service name.

[igpeev]

@luisfpg Thanks for the clarification. What would be your recommendation for this use-case.

Say API yaml defines GeneralError (model) and WeekDay (enum). In code I can use WeekDay.Monday (ok), but I also need new GeneralError('some text'). So I go ahead like:

import { GenealError as IGeneralError } from ...
export class GeneralError implements IGenaralError { ... }

my thought was more in line with (make somehow models/interfaces look like models/interfaces out-of-the-box, so as not to rename imports to avoid name chalsesh).

import { IGeneralError } from ....
export class GeneralError implements IGeneralError { .. }

Thanks

[luisfpg]

The interfaces cannot be instantiated, but can be used directly. You shouldn't create any class implementing the generated interfaces. Just do:

const error: GeneralError = {
    code: "0001", ...
};

[igpeev]

Not quite what the ask is. We need possibility to namespace interfaces/models, but not enums. This snippet gives sample scenario in which inline object declarations fail. The use case is for code (existing/libs) that require instance of a class (e.g. new GeneralError(...), but not {...} as GeneralError). Thanks

class A {
    foo: string;
}

class B {
    dontHaveFoo: number;
}

const a1 = new A();
a1.foo = 'some text for instanceof A';

const a2: A = {
    foo: 'some text for inline object creaton',
};

const b = new B();
b.dontHaveFoo = 33;

function process(param: A | B) {
    if (param instanceof A) {
        console.log('doing sth for A', param);
        return;
    } else if (param instanceof B) {
        console.log('doing sth for B', param);
        return;
    }

    console.log('Error: neither A nor B', param); // <-- this is where `a2` goes
}

process(a1);
process(a2); // <-- logs: Error ... 
process(b);