I have a few projects written on Typescript.
TS has a declaration files (d.ts) to declare non-ts libs. How it's works in Dart?
Dart looks very cool but I'd like to use Backbone and Marionette in my project.
Is there opportunity to rewrite projects at Dart or use Dart in next project using Marionette?
There are some attempts or plans to support that better but currently I guess this isn't too easy.
dart:js provides support to call between Dart and JS but this probably won't work with d.ts. You'd need to rebuild d.ts for dart:js.
Support for d.ts seems to be work in progress and a first version should become available in the not too far future https://github.com/dart-lang/sdk/issues/23423
The dev_compiler team is working on generating TypeScript output from Dart code https://github.com/dart-lang/dev_compiler/issues/397. I don't know about the status. Seems to be farther away.
You probably want to look at package:js, https://pub.dartlang.org/packages/js and see the ChartJS example there. Angular has a ts2dart compiler, but I don't know if that would actually convert the d.ts files or if you'd need to do that by hand. It doesn't seem like it would be too difficult to turn d.ts definitions into package:js definitions.
What is the best solution for including vanilla JS libraries in TypeScript projects? This is one of those things that "works" just fine, but I feel like I'm clearly not going about this in a "best-practices" sort of way.
Let's say, for example, that you want to use EaselJS in an Angular project. You can just add a link to CreateJS in your index.html file as usual, and then you have access to the global createjs object, but your compiler will of course know nothing about createjs, and will assume that you've got an error. What's the best way to let TypeScript know about this external source?
Moreso, what's the best way to enable auto-completion so that when I type "createjs." I get a list of the methods in that file? Is mixing JS and TS like this possible?
I suppose I could create a TypeScript shim that passes things through to the createjs object, but then that shim would be riddled with "errors."
Thoughts?
Thanks!
Oh, looks like this is done via a definition (.d.ts) file. There's a good tutorial here. In fact, CreateJS already has one of these available here, and if you go up a level in that Github Repo you'll find tons of these definition files in the DefinitelyTyped repository. I haven't tried this out yet, but it looks like the right direction.
You should use ambient declaration.
declare var createjs;
You use ambient declarations to tell the TypeScript compiler that some other component will supply a variable.
Is anyone working on TypeScript definitions for ExtJS 5? I keep checking DefinitelyTyped but there is no activity:
https://github.com/borisyankov/DefinitelyTyped/tree/master/extjs
I started researching this question in earnest, but found the search results rather unfulfilling.
First of all, here is a small discussion which provides some insight into Sencha's view on TypeScript.
While I couldn't find anything specific to ExtJS 5 (my apologies), I did find this link, which claims to generate TypeScript declaration files using a process that starts with ExtJS documentation. The examples target ExtJS 4.1, but perhaps it could work with ExtJS 5. If so, it would solve your problem. That certainly isn't an answer, but perhaps it's a lead.
As an aside, the conversation referenced above didn't sit right with me. It begins with a seemingly innocent request for Sencha to consider the potential that TypeScript provides for static tooling.
TypeScript
I just spotted TypeScript (http://www.typescriptlang.org/), and it
looks promising. Has anybody had a chance to play around with it yet?
I want to understand if it would be possible to produce a TypeScript
declaration file to declare all the types from the Ext JS and Sencha
Touch frameworks. I'd love to have better static analysis and tool
support for my Sencha development work.
Thanks!
This is the response from a Sencha Senior Forum Manager:
Just another thing to make things ugly [TypeScript]
[EDIT] Regardless of how many times I say this comment was obviously a
personal comment, it's still personal. If you haven't talked to me or
followed me on Twitter or anything, I'm anal about my code and the
syntax that TypeScript (even ES6) is ugly.
That's pretty harsh!
I don't know the forum manager personally, so I am not going to speak to his particular bias against TypeScript. But I do think I can provide some insight into why Sencha representatives might not be rooting for it's success. Perhaps this will help you understand why it might not be a high priority for many people to create a definition file for ExtJS 5.
Please note that I could be wrong and there is an ExtJS 5 definition file out there that just hasn't made it to DefinitelyTyped yet. My search was far from exhaustive.
TypeScript
Here is a simple example of the model of object-oriented programming that TypeScript uses.. Notice that a constructor is a function which returns an instance whose state has potentially been modified or specialized from that of its prototype:
function Mammal() {
//...
}
The constructor's prototype property, which happens to be the prototype of the object returned by the constructor, can then extended with methods and properties (in the ES5 Object.defineProperty sense). The members that are declared on the prototype do not have to be recreated for every instance created by the constructor:
Mammal.prototype = function giveBirth() {
//...
}
In this sense, the constructor is playing the role of a class, and the structure of its prototype property defines the type of object that is created by the constructor. While this pattern is quite verbose in ES3 and ES5, especially when adding in the additional machinery required for inheritance, it is the pattern used by ES6 to define the notion of a class. Therefore, it is the pattern used by the TypeScript compiler to compile a class.
For a more complete treatment of this form of classical object-oriented programming in JavaScript, along with techniques for making classical inheritance more succinct, see this post by Douglas Crockford.
What's noteworthy is that the notion of a type exists only at design time, and is enforced by the TypeScript compiler to help you write sturdier code.
ExtJS
Before TypeScript existed, I had become familiar with the model of classical inheritance employed by Sencha's ExtJS framework. This model provides a means for defining classes and creating instances from their corresponding types using several patterns, including the module pattern and the prototype pattern and the factory pattern. If you are an ExtJS programmer, you'll find these patterns quite familiar, but for reference, please refer to the appropriate sections of Learning JavaScript Design Patterns by Addy Osmani.
As a pure JavaScript developer, this method of classical object-oriented programming is powerful. It is similar in many respects to the model of classical object-oriented programming used by the TypeScript compiler, but with one key difference. In ExtJS, a class and its type are known to the framework, and therefore exist at run time. One of the best things about ExtJS is that it simulates the syntax of creating a class, much like one might do in Java or C#. But it is pale in comparison to the method of specifying a class in TypeScript.
When first introduced, I was so enamoured by the method of class definition employed by ExtJS that I created a library of my own called classical. I was inspired enough to create my own library in order to explore and extend class definition in JavaScript, and to implement it for my own edification. If you click the link above, you'll notice that the project has evolved away from an ExtJS-like class system, and into a base class library for TypeScript.
Why the change?
For starters, TypeScript provided a model of object-oriented programming which not only allowed me to utilize familiar OOP design patterns, but also provided me with a static type system and all the design-time tooling that went along with it. When first discovering TypeScript (version 0.8), my initial reaction was to create a type definition file for classical, which would be a similar (but much simpler) endeavor to creating one for ExtJS. After I had completed this task, the syntax of the resulting library was an utter disaster! I'd like to explore what went wrong, and I'll do so with a simple example from ExtJS.
This code is taken from the discussion mentioned above, and looks like a standard ExtJS class definition:
Ext.define('WebApp.model.RenderableRecord', {
extend: 'Ext.data.Model',
idPropert: 'id',
isRenderableRecord : true,
fields: [
{ name: 'id', type: 'string' },
{ name: 'name', type: 'string' },
{
name: 'renderable',
convert: function (val, model) {return val;}
},
],
renderItems: function (renderer: Function) {
var me = this;
return function (config: Object) {
renderer(me.get('renderable'), config);
}
},
});
Consider the interface that is defined by the prototype above. If static typing in TypeScript was desired, one might create an interface that looks something like this:
module WebApp {
module model {
export interface RenderableRecord extends Ext.data.Model {
idPropert: string;
isRenderableRecord: boolean;
fields: Array<Field>;
renderedItems(renderer: Function);
}
//Assume Ext.data.Model and Field are defined already
//and that the Field interface looks something like this:
export interface Field {
name: string;
type: string;
convert: Function;
}
}
}
Not only would that interface have to be defined alongside the ExtJS definition, but instances would have to have their type specified twice, once as WebApp.model.RenderableRecord (or as a string of the same name when calling Ext.create) and then again by casting it to the appropriate TypeScript type. That's a lot of work to get static typing that is, as a result of the casting, still error-prone!
So what's the problem?
The problem is that there are two type systems in play. One is the design-time type system enforced by the TypeScript compiler. The other is the run-time type system defined by ExtJS. These two type systems are very similar in regard to the way they are implemented, yet they each have a distinct syntax, and therefore have to be specified seperately. Much of the value of a static type system is lost if it two copies of every interface have to be maintained.
Here is a more complete treatment of the hurdles that one must overcome when integrating TypeScript and ExtJS. It also references the GitHub project above. The author concludes that
Unfortunately, TypeScript and ExtJs do not seem to work too well
together.
The bottom line is that ExtJS and TypeScript both define their own type systems, which don't quite play by the same rules. Therefore ExtJS and TypeScript are fundamentally incompatible with each other...
...okay fundamentally is too strong a word, but it takes a lot of work to use the two tools together effectively. So if I was a Senior Forum Manager for Sencha, I might not be rooting for TypeScript either.
Personally, I prefer the ES6 preview, the static type system and the design-time tooling provided by TypeScript. And it's a shame I have to even choose because the two aren't of the same type - one is a framework and the other is a language. And some folks sure do go to great lengths to make them compatible.
ExtJS is a powerful JavaScript framework, which I'm sure has only grown richer in time. But as it is, ExtJS is at it's best when used as a JavaScript framework. Or to quote that same forum manager:
...you can write correct and productive JavaScript without the need of
any compiler like coffeescript or typescript.
ExtJS provides one approach to classical object-oriented inheritance in JavaScript as a framework. TypeScript provides a second approach as a language. If you're interested in TypeScript, take a look at classical. It is far from a professional framework like ExtJS, but it does provide an opinion about what tools might look like when built for TypeScript developers.
I have recently been working on some Typescript definitions for ExtJS, and also contributing to another project that provides a forked Typescript compiler that is more compatible with ExtJS.
See https://github.com/fabioparra/TypeScript
Maybe I answer after a time when the thing is no longer up-to-date, but I created
TypeScript definitions for Ext.JS 5, 6 and 7, because there were a lot of reasons
not to go by ways above:
Patched TypeScript compiller is no longer active. Today TypeScript version is far away from it.
Patched TS compiller is cool, but the TS compiller is too complicated project to maintain
(for Ext.JS classes generating) for me.
The "Premium TypeScript definitions" on https://github.com/thanhptr/extts have
a lot of mistakes and I mean a lot. For example the first call you need
Ext.application({}); is nowhere.
JS Docs in github.com/thanhptr/extts contains HTML syntax, which is not so readable for day work.
Ext.JS TypeScript generator on github.com/zz9pa/extjsTypescript is too simple and not possible
to use for higher Ext.JS versions (5, 6 and 7), but it was the main impulse to create
new Ext.JS TypeScript definitions generator here.
My solution is based on the same principles like this blog post: "Using ExtJs with TypeScript".
But there are a few differences. I thing all differences could be clear from examples:
Example in Ext.JS 5.0.1
Example in Ext.JS 6.0.1 classic
Example in Ext.JS 6.2.0 classic
Example in Ext.JS 7.0.0 classic
The main differences are:
All classes are generated as they are.
All members from 'overrides' files are also generated.
Singleton classes like Ext, Ext.Array etc. are also generated properly.
Classes configurations are placed in *.Cfg interfaces, for example:
Ext.panel.Panel has config interface in Ext.panel.Panel.Cfg.
To extend class, you need more than class config (you need object members like
extend, requires, config, statics or maybe also template methods),
so that's why there are also generated interfaces to have extended class definition:
class extended from Ext.panel.Panel has interface for definition in Ext.panel.Panel.Def.
There are also generated self properties in better way.
There are generated interfaces for listeners/events, for example:
Ext.panel.Panel has interface for events in Ext.panel.Panel.Events.
There are also generated a lot of interfaces for structured method params and more.
There is of course possible to create an application with modern toolkit, but Id didn't make any examples:-).
The solutions supports autocomplete everywhere and Visual Studio code refactoring by CTRL+R, which is very very practical:-)
Please go to find ExtTS - Premium TypeScript type definitions for Sencha Ext JS
https://github.com/thanhptr/extts
Almost every latest versions of ExtJS 4.x, 5.x, 6.x is supported, currently latest version is 6.0.2.437.
Everything you can find from ExtJS API document is in the type definitions with strongly-typed support (such as: Ext.dom.Element, ButtonConfig,..)
There is definitely a room for ExtJS TS definitions
While it's true that TypeScript and ExtJS use incompatible class systems some strategies may be used as a workaround:
Use a patched TS compiler
The ExtJS emitter developed by fabioparra and linked here by Gareth is one possible workaround.
IMHO the main drawback is that it complicates the integration with IDE supporting the TS language. For instance there is no documentation regarding the compatibility of this solution with existing Eclipse TS plugins.
Moreover it is not sure that the development of patch will be maintained for future versions of TypeScript.
Use TS static methods as a factory of ExtJS objects
The idea here is to provide a set of static methods replacing the constructors of ExtJS classes. It becomes thus possible to instantiates ExtJS objects while using the legacy TS compiler.
I have recently delivered this alternative solution named TypExt on github (https://github.com/david-bouyssie/TypExt).
Note that it has to be used in conjunction with proper ExtJS TS definitions (https://github.com/david-bouyssie/TypExt/tree/master/typescripts).
Currently only ExtJS 5.1.1 is supported but I plan to extend the usage of TypExt with other ExtJS versions.
I need to add a image upload function to extjs htmlEditor, and I searched the web and found that 2 different solutions are out there. One is to use plugins arrays, in which are the plugin classes extending the util.Observable class(and to make things even confused, they all contain something called MidasCommand, what is this anyway it's not in the documentation), the other is writing a extending class for form.htmlEditor.
Can someone please explain which should I choose and why, and also what about Ext.override and Ext.extend? Are they the same thing?
AFAIK the difference between extending and plugins is:
Plugins are reusable. If you need the extension code only once, then a plugin would be over-engineerd somehow. With plugins you can have a single source for extending many classes.
Ext.override don't create new classes, but modify an existing class. Ext.extend creates a new class.
Regarding your editor, I'm afraid I cannot help you. I've found Midas Spec. Seems that this hasn't been developed further, but maybe I'm wrong.
I want to develop using C & C++ using XCode 5. I particularly like the integration of XCTest and Xcode and the CI capability that you get by using OSX Server. I want to have a mocking framework, and ideally one where the mocks are automatically generated, as this seems most likely to ensure that the mocks follow a standard format (and themselves are not going to have errors).
Q1. I can't see how OCMock can work for mocking C & C++: is this possible?
Q2. CMock seems to be great, but it relies on Unity. Is it possible to integrate CMock into XCTest?
Q3. Does anyone have any other suggestions please?
Q1. OCMock can only mock methods on Objective-C classes, objects, and protocols.
Q2. What is Unity? (And I'm asking this as the maintainer of OCMock...)
Q3. There are several options for C and C++, I don't have much experience, never mind a strong recommendation.