Component and option type definitions + code docs

[mauromascarenhas]

Proposed changes

Apply type definition for every Materialize component (I have taken some from DefinitelyTyped, since I'm the maintainer of @materializecss/materialize types).

• Base Component is a generic class with "BaseOptions" interface:
  • Declared function overloades for component initializer;
  • Declared "virtual" methods and given a proper documentation for them.
• Every component (except by Toast) inherit from Component and their respective options from BaseOptions;
• Removed "circular" dependencies (check "Breaking changes");
• Added missing types to event handlers and their respective args;
• Component options is no longer "protected" (the user should be able to check the initialization options as well, just as mentioned in the docs);
• Fixed:
  • Undefined instance reference in Collapsible "destructor";
  • Touch event handler when target does not have a close carousel item;
  • Type definitions using "Boolean" object as type.

Breaking changes

• Completely removed native support to jQuery;
• Unused methods, such as M::objectSelectorString, have been removed;
• Global utility functions and variables have been migrated to "Utils" module, which is available under "M.Utils" (this is an important change, since it removes circular dependency from the component sources 😃).

Affected PRs:

• Typescript classes for component options #351 Should be closed, since it would become redundant;
• Icon tabs #370 Should be refactored in order to match component types;
• Replacement for standard search function in autocomplete #387 Should be refactored in order to be merged;
• fix: avoid overwritting of base property 'el' in 'Component' #388 Should be closed, since it would become redundant.

Types of changes

• Bug fix (non-breaking change which fixes an issue).
• New feature (non-breaking change which adds functionality).
• Breaking change (fix or feature that would cause existing functionality to change).

Checklist:

• I have read the CONTRIBUTING document.
• My commit messages follows the conventional commit format
• My change requires a change to the documentation, and updated it accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[danice]

Great work!
One thing: I have tested the changes in this test project an it gives errors for the init method:

The reason is that querySelectorAll returns a NodeListOf<Element> instead of NodeListOf<HTMLElement>.
One possible solution to avoid having to add this querySelectorAll<HTMLElement> all the time would be changing the init parameters to

static init(els: InitElements<Element>, options: Partial<CarouselOptions>): Carousel[];

instead of the

static init(els: InitElements<HTMLElement>, options: Partial<CarouselOptions>): Carousel[];

What do you think?

[mauromascarenhas]

Great work! One thing: I have tested the changes in this test project an it gives errors for the init method:

The reason is that querySelectorAll returns a NodeListOf<Element> instead of NodeListOf<HTMLElement>. One possible solution to avoid having to add this querySelectorAll<HTMLElement> all the time would be changing the init parameters to

static init(els: InitElements<Element>, options: Partial<CarouselOptions>): Carousel[];

instead of the

static init(els: InitElements<HTMLElement>, options: Partial<CarouselOptions>): Carousel[];

What do you think?

Well, I haven't noticed it. Thanks for reporting.
I'll replace this type requirement in initialization functions and constructors.

UPDATE

From what I've seen, this issue only applies to "NodeList". Therefore, I'm just updating the "init" function overload types.

[mauromascarenhas]

@danice, I've made some changes to the initialization overloads which allows "Element" type to be considered as well 😄. The following snippets illustrates a picker being initialized either by a single element (even though it is typed as HTMLInputElement) or by a NodeListOf<Elements>.

I've also updated component initializers so as to allow "empty" options 😃.

[wuda-io]

Haha good work! That will take some time to review 😆 I will check locally...

[mauromascarenhas]

I've just had to merge v2-dev into this branch, since #387 has been already merged, thus, requiring a small refactor, as mentioned in the topic.

[wuda-io]

Awesome! Great work 👍
I see you used some sort of documentation tool in your code. Is this TSDoc?

[mauromascarenhas]

It is JSDoc as well.
Since TS is a superset of JS, most of JSDoc tags also work with TS.