fix: fix typescript errors

[yaroslav8765]

No description provided.

[Copilot]

Pull Request Overview

This PR fixes TypeScript errors across the codebase by adding proper type annotations, correcting imports, and resolving type inconsistencies.

• Added explicit type annotations throughout Vue components and TypeScript files
• Fixed import statements to use correct paths and type exports
• Refactored duplicated type definitions into reusable interfaces

Reviewed Changes

Copilot reviewed 21 out of 22 changed files in this pull request and generated 8 comments.

Show a summary per file

File	Description
adminforth/types/Common.ts	Added FieldGroup type, imported AdminForthActionInput, refactored field group definitions
adminforth/spa/vite.config.ts	Added type annotations for function parameters and error handling
adminforth/spa/src/views/ShowView.vue	Fixed type imports and added type annotations for computed properties and functions
adminforth/spa/src/views/ListView.vue	Added comprehensive type annotations and fixed array handling logic
adminforth/spa/src/stores/modal.ts	Made ModalContentType properties required instead of optional
adminforth/spa/src/spa_types/core.ts	Updated import path for AdminForth types
adminforth/spa/src/components/*	Fixed type annotations, event handlers, and prop definitions across multiple components
adminforth/spa/src/afcl/*	Added proper TypeScript annotations for form components
adminforth/spa/src/adminforth.ts	Fixed duplicate imports and corrected function return types

Files not reviewed (1)

• dev-demo/package-lock.json: Language not supported

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[SerVitasik]

Do you return result of getList?

[yaroslav8765]

adminforth.list.refresh method expect us to return only an error. await getList(); will be executed anyway

[SerVitasik]

Ok, then why do you return empty objects?

[yaroslav8765]

Because refresh(): Promise<{...}> its not a Promise and it still has to return something

[SerVitasik]

Why we can't return something if !result and ok: true or false?
For example like this

adminforth.list.refresh = async () => {
  const result = await getList();
  if (!result) {
    return { error: "Failed to refresh", ok: false};
  }
  if ('error' in result && result.error != null) {
    return { error: String(result.error), ok: false };
  }
  return {ok: true};
};

refresh(): Promise<{ error?: string, ok: boolean}>

[yaroslav8765]

This branch is not about re-writing FrontendAPI. Change refresh(): Promise<{ error?: string, ok: boolean}> will cause a lot of new TS error, which will have to be resolved as well. Does adding ok: boolean will give us any advantages?

[ivictbor]

@SerVitasik good finding, I think that indeed we see that logic changed - refresh previously returned all data but now it will return only error if it happened.
However type is controversial to what happened before - type actually said that only error could be returned but not all data. So I can understand Yaroslav - actually he tried in this code to follow type implementation.

So in such tasks we need to decide, whether we will stick to type or actual behavior we had before. And we need to be indeed very careful when we removing actual backward compatibility - if some code was reading results of refresh, it will brake now fully.

But I ask question to myself - is it really needed that some code should read from refresh? I mean imagine case you are using refresh - generally it is just to update table, not to fetch actual data. If you have idea where you need exactly read all data from refresh - please write it. If we will need it we can create another task where we need both to change type, maybe even add prop like { error: ..., data... }
For now I think implementation corresponds to type

[SerVitasik]

This branch is not about re-writing FrontendAPI. Change refresh(): Promise<{ error?: string, ok: boolean}> will cause a lot of new TS error, which will have to be resolved as well. Does adding ok: boolean will give us any advantages?

Yes, it is. At the very least, if we have an empty result, the user will see an error rather than an empty object. And it is always better to see ok: true than an empty object when the operation is successful.
As for returning the data, i don't think we need it. Personally, i only use list.refresh() for updates.

[SerVitasik]

Ok, then why do you return empty objects?