🔀🎉 nameSchema module as replacement for v3 renameFz

[buffcode]

What kind of update does this PR provide? Please check

• new translations / updated translations / translation fixes
• a new feature
• a new module
• a bugfix for an existing feature / module
• improvement of style or user experience
• other: Please fill out

What is included in your update?

• new module nameSchema
  • rename vehicles at dispatch, building and vehicle level
  • rename building at dispatch and building level
  • multiple strategies and formats for unit/building numbering
  • batch renaming
• removal of renameFz module

Additional notes

• Todo (see [Feature Request]: Module: RenameVehicles #26):
  • presets
  • template preview

[Cr4zyc4k3]

temptating = templating? 😄

[Cr4zyc4k3]

Despite my argument with kdev (we agreed to argue about spelling alphabets via PN and dont bother the development with stuff like this). What is the current status of this PR? Looking forward to see it ingame 😊

[buffcode]

Despite my argument with kdev (we agreed to argue about spelling alphabets via PN and dont bother the development with stuff like this). What is the current status of this PR? Looking forward to see it ingame 😊

I don't have so much time currently. I tried to implement the template preview, but the Settings Vue Component doesn't seem to be compatible with the composition API currently, at least I was unable to satisfy Typescript, though the project could be build.

I have a v3 import feature locally, that enables a button to import existing settings from renameFz when the respective localstorage item is detected. If wanted I can add it to this PR as well.

[jxn-30]

Typescript doesn't check within vue files while compiling and building LSSM currently.
As long as it works, it's currently okay if Typescript would fail. We will have to have a look at all the vue files after migrating to vue3, so till than a more or less hacky variant is okay in my eyes.

TypeScript Support will also get better when all stores are migrated to setup stores (and settings store is one of them that needs full rewrite), so I hope that maybe we will even reach a point where LSSM-Settings are fully typed, which allows perfect type checking within setting components. But that is just future thinking ^^

The import button would be very nice, push is welcome :)

[jxn-30]

Just to be clear: I am not happy with hacky solutions being necessary but I expect them to be much less necessary in the future (hopefully not too far away) ^^

Try are still allowed as long as not-hacky ones are frustratig

[buffcode]

Typescript will fail with:

### [🚨] check TypeScript ###
src/modules/nameSchema/settings.ts:208:9 - error TS2741: Property 'default' is missing in type 'Omit<Custom<never, never, never, never, never, never>, "default" | "value" | "isDisabled" | "properties">' but required in type 'Omit<SettingType<unknown, Record<string, never>, DefaultData<Vue>, DefaultMethods<Vue>, DefaultComputed, DefaultProps>, "value" | "isDisabled">'.
208         importFromRenameFz: {
        ~~~~~~~~~~~~~~~~~~
typings/Setting.d.ts:172:5
172     default: AppendableListItem[];
    ~~~~~~~
    'default' is declared here.
Found 1 error.

[jxn-30]

Hmm, I will have a look at it tomorrow. I think, that's one of the situations where it becomes very hacky 😅🙈

[jxn-30]

Found a hacky way where TypeScript doesn't complain:

importFromRenameFz: <Omit<Custom<null>, 'isDisabled' | 'value'>>({
    type: 'custom',
    component: ImportSettingComponent,
    default: null,
    properties: {},
    disabled() {
        return (
            window.localStorage.getItem('lssm_LSS_RENAMEFZ_STORAGE') ===
            null
        );
    },
} as unknown),

I know how hacky that is, but it works and improving Types of the Settings is already on my TODO :)

[Cr4zyc4k3]

Is there anything we can do to help you get this PR merged? 😃