Hi Thanh,
First of all congrats for the great job on extjs type definitions.
On begining of 2015 I made some movements on a very large project using extjs to have support to intellisense/static validation.
After a big research I found DefinitelyTyped but it could not be used as reference for our project.
We construct our own definition file based on jsduck and original Sencha documentation (with many errors) + a very little customization on Sencha code..
As the lack of qualified docs we need to make some assumptions, and some may be wrong.
Now we want to move to a more established definition file.
I have take a brief look on yours since I always looked at Fabio's progress on generating extjs based on Typescript transpilation.
I need to ask you. How you deal with:
Exjjs aliases and alternate class names in definition files. As some projects comeing from extjs 3 and are not standarzied
Singletons inheriting from regular classes and not extending then like Ext.MessageBox (singleton) that extends Ext.widow.MessageBox (regular class)
I never found nothing about the best way to support this, as our files have big dependencies on it.
I think the short way is to declare the alternate and aliases as empty extends of principal ones, but I know it's not really a case of inheritance at all, but extjs has a lot of alias and alternate class names.
I tried to use typescript type aliases on declarations but with no all luck as the separation of type and value as stated by Anders and others.
You plan to include then in some version of your definition types?
I really want to change to your definition files and can contribute to fix some little mistakes i found here.
Have you any plan to share this definitions with DefinetlyTyped. As of all definitions I saw to extjs yours seems like most accurate.
Regards,
Hi Thanh,
First of all congrats for the great job on extjs type definitions.
On begining of 2015 I made some movements on a very large project using extjs to have support to intellisense/static validation.
After a big research I found DefinitelyTyped but it could not be used as reference for our project.
We construct our own definition file based on jsduck and original Sencha documentation (with many errors) + a very little customization on Sencha code..
As the lack of qualified docs we need to make some assumptions, and some may be wrong.
Now we want to move to a more established definition file.
I have take a brief look on yours since I always looked at Fabio's progress on generating extjs based on Typescript transpilation.
I need to ask you. How you deal with:
Exjjs aliases and alternate class names in definition files. As some projects comeing from extjs 3 and are not standarzied
Singletons inheriting from regular classes and not extending then like Ext.MessageBox (singleton) that extends Ext.widow.MessageBox (regular class)
I never found nothing about the best way to support this, as our files have big dependencies on it.
I think the short way is to declare the alternate and aliases as empty extends of principal ones, but I know it's not really a case of inheritance at all, but extjs has a lot of alias and alternate class names.
I tried to use typescript type aliases on declarations but with no all luck as the separation of type and value as stated by Anders and others.
You plan to include then in some version of your definition types?
I really want to change to your definition files and can contribute to fix some little mistakes i found here.
Have you any plan to share this definitions with DefinetlyTyped. As of all definitions I saw to extjs yours seems like most accurate.
Regards,