fix(types): better declaration files

[prudho]

Description

This is the first round of fixes/improvements for type declarations of Fomantic. Some properties and methods were missing, some were too restrictive.

I've enabled strict type checking on my work project (~500k lines of code and use almost every module of Fomantic). Before the fix I had around 2500 errors during transpilation, 0 after.

I just cannot fix one error, that I circumvent by adding the //@ts-expect-error on the line before:
For a Form, creating a new rule will raise an error in VSCode (that can be safely bypassed).

$.fn.form.settings.rules is typed and Intellisense is working, but adding a new rule to it will trigger an error. Anyway, this is not a blocking issue for merging, since this PR will make a lot more good than bad :)

Closes

#2906

[lubber-de]

LGTM
That must have been a PITA to investigate and fix.
Thanks for your effort! 👍🏼

[KiddoV]

Thanks for the PR. There are still a few issues, at least in my application:

1. stateContext should also be a string?
   https://github.com/prudho/Fomantic-UI/blob/17cad4ed74a71c16d1e3b05f19b99e24bd8aff0b/types/fomantic-ui-api.d.ts#L140
   Should it be => stateContext: false | string | JQuery; ?

2. Conflict with JQueryAjaxSettings when using FomanticUI.API that has some keys already existed in JQueryAjaxSettings:
Will causing No overload matches this call. ts(2769), When using: cache, method, etc...
Maybe do => Omit<JQueryAjaxSettings, "method"> and Omit<JQueryAjaxSettings, "cache">, etc...

2. Case insensitive for method in FomanticUI.APISettings?
   I am using "GET", "POST".... without any error in runtime so I assumed no case sensitive here?
   So either do this:

method: Uppercase<'get' | 'post' | 'put' | 'delete' | 'head' | 'options' | 'patch'> | Lowercase<'get' | 'post' | 'put' | 'delete' | 'head' | 'options' | 'patch'>;

or

method: string | undefined; //same as AjaxSettings.method

3. Not sure what causing these error for FomanticUI.Search:
   
   ...also FomanticUI.Dropdown
   
   

Otherwise, everything is looking better than the old version...

[KiddoV]

Please also check a few more error I just found out here:



...

[KiddoV]

Also onSuccess with fields should be {[key: string]: any} instead of object[]?
https://github.com/prudho/Fomantic-UI/blob/17cad4ed74a71c16d1e3b05f19b99e24bd8aff0b/types/fomantic-ui-form.d.ts#L313

... so that we can use: fields.fieldName instead of fields["fieldName"]?

[KiddoV]

I just cannot fix one error, that I circumvent by adding the //@ts-expect-error on the line before: For a Form, creating a new rule will raise an error in VSCode (that can be safely bypassed).

$.fn.form.settings.rules is typed and Intellisense is working, but adding a new rule to it will trigger an error. Anyway, this is not a blocking issue for merging, since this PR will make a lot more good than bad :)

For this error I would suggest doing this:
Add this to line 294:

rules: Form.RulesSettings & {[key: string]: (value?: any, identifier?: string, module?: any) => boolean};

So we can add custom rule but keep the original
Also add this for custom prompt:

prompt: Form.PromptSettings & {[key: string]: string | undefined};

To line number 282

[lubber-de]

@KiddoV
This would also be needed for Modal / Flyout templates (Modal.settings.templates / Flyout.settings.templates )as those can be enhanced by custom templates as well

@prudho Would you like to investigate into the above mentioned findings and add commits to this PR before merging?

[KiddoV]

Please check out my PR #2915 for reference. I fixed almost all of errors from my application based on @prudho PR and some additional fixes for those comments from me above.
NOTED: There could be more error that I haven't spotted.

[prudho]

I just cannot fix one error, that I circumvent by adding the //@ts-expect-error on the line before: For a Form, creating a new rule will raise an error in VSCode (that can be safely bypassed).

$.fn.form.settings.rules is typed and Intellisense is working, but adding a new rule to it will trigger an error. Anyway, this is not a blocking issue for merging, since this PR will make a lot more good than bad :)

For this error I would suggest doing this: Add this to line 294:

rules: Form.RulesSettings & {[key: string]: (value?: any, identifier?: string, module?: any) => boolean};

So we can add custom rule but keep the original Also add this for custom prompt:

prompt: Form.PromptSettings & {[key: string]: string | undefined};

To line number 282

This is clever ! I tried a lot of stuff to make it work but your solution works great and doesn't break Intellisense 👍

I've pushed another bunch of fixes based on your feedback, many thanks @KiddoV !

@lubber-de yeah, let's wait a few more fixes before merging it.

[KiddoV]

@prudho, thanks for the update from the second commit!
There are a few more suggestions, errors I would like to point out:

---

I - API

Line 146

stateContext: false | string | JQuery<any>;

Since I can pass in JQuery<EventTarget> without any problem in runtime.

---

II - TRANSITION

This is valid in runtime $(".main-msgbox").transition("shake", "200ms");.
So add duration?: parameter for each transition?
e.g.

(behavior: 'shake', duration?: string | number): JQuery;

---

III - FORM
In the callback functions, return fields should be any or {[key: string]: any} instead of object[].
E.g. line 313

onSuccess(this: JQuery, event: Event, fields: {[key: string]: any}): void;

Since I can use fields.fieldName instead of fields["fieldName"] no problem in runtime.

---

IV - SEARCH
Search is missing some settings. See my suggestion on line 230 -> 248
https://github.com/fomantic/Fomantic-UI/pull/2915/files#diff-0090b6d98fc5dea01a7a7f0056b2e55b5fd9e9bad4f689236186f61c3f7b1b25R231-R248

Also onSelect callback result should be any?

onSelect(this: JQuery, result: any, response: object): void | Promise<void> | boolean | Promise<boolean>;

---

V - POPUP
Callback onShow should just return boolean? I leave my function return nothing and it still work in runtime. So add void?

onShow(this: JQuery): boolean | void;

[prudho]

Definitely many thanks @KiddoV. All the difficulty here is to set "probable" types to a framework that can accept virtually anything 😄 Your help is very appreciated !

I've implemented your suggested changes, and added a few more by reviewing code and internal uses.

[KiddoV]

@prudho Thank you! Your latest commit make my VSCode happy... for now, so I am cool! 😁
This types feature still definitely need a lot more works. I will give more suggestions if spotting anything else!

[lubber-de]

LGTM! 👍🏼