Calling properly TypeScript code from JavaScript

On our big enterprise project we faced a situation that seems not to be very well described in the articles and the posts available in the Internet.

We need to integrate our existing JavaScript infrastructural code that supports SPA with the code that is being developed by the other team on TypeScript. We can’t drastically change the approach (i.e. just pick a single language) for many political limitations and the development resources available. And we fully understand that’s probably it’s not a good idea to integrate two pieces of infrastructure together that are written on different languages.

Still we need to evaluate the impact and best practices of calling TypeScript from JavaScript code.

The justification that TypeScript is essentially compiled into JavaScript seems to be obscure because there are no trustful sources on information on the topic on how to properly consume that compiled JavaScript from handwritten JavaScript and what are the hidden caveats (or alternatives).

It also seems that the opposite situation when TypeScript code needs to call JavaScript is surprisingly very well described.

Any profound thoughts on the topic?

UPD

Specifically here is the list of questions we are seeking the answers now:

  • what will be the JavaScript shape of the TypeScript API that extensively uses generics, class hierarchies, interfaces?
  • are there any issues with bundling, minification, AMD?
  • is it possible to have the basic Angular controller written in TypeScript and the other JavaScript Angular controller that inherits the functionality from it? What will be the caveats?

Actually we think that we haven't surfaced all the questions yet. They've emerged just after a couple of hours of thinking on that topic.

Answers:

Answer

Simply said, if you have to integrate/use a library which is written in Typescript in your own project which uses JavaScript, you will use the compiled JavaScript API!

You basically throw away everything which TypeScript brings in terms of benefit over pure JavaScript.

Meaning you don't have to care about anything specific to TypeScript, like generics etc. You only have to work with the compiled output of the TypeScript library...

To give you an example, go to http://www.typescriptlang.org/Playground Select "Walkthrough: Generics". On the right you should see the compiled JavaScript. It has no generics or anything special, it still is pure JavaScript. That's what you have to deal with...

to your "specific" questions:

  • what will be the JavaScript shape of the TypeScript API that extensively uses generics, class hierarchies, interfaces? See above. It will be plain good old Javascript. No difference for you.
  • are there any issues with bundling, minification, AMD? No, because compiled TypeScript is plain JavaScript and can be minified etc...
  • is it possible to have the basic Angular controller written in TypeScript and the other JavaScript Angular controller that inherits the functionality from it? What will be the caveats? Yes of course you can do whatever you want with the compiled JavaScript.

The only disadvantage of using the compiled JavaScript from Typescirpt is, that you throw away the awesome features TypeScript can give you, like... types... If the other team is already on that route, you may want to consider to write your part in TypeScript as well ;)

Answer

The justification that TypeScript is essentially compiled into JavaScript seems to be obscure because there are no trustful sources on information on the topic on how to properly consume that compiled JavaScript from handwritten JavaScript and what are the hidden caveats

Consuming TypeScript from JavaScript is the same as consuming TypeScript from TypeScript, or JavaScript from JavaScript for that matter. For example, let's say you have a function in TypeScript:

function f(n: number) { return 'the number is ' + n; }

To call this function from TypeScript, you would write

var x = f(42);

To call this function from JavaScript, you would write

var x = f(42);

Let's say you have a class in TypeScript:

class MyClass { /* ... */ }

To use this class from TypeScript, you would write

var c = new MyClass();

To use this class from JavaScript, you would write

var c = new MyClass();

In other words, it's exactly the same. No guidance has been given because none is needed.

Answer

I think is not a Typescript problem.

You could see the same 'issue' (issue,not a problem) with Cofeescript , dart, traceur , or any other transpiler.

Javascript as a platfom, is very susceptible to devs's experience, language understanding and skills. (like any other language? )

If someone has a hardtime reading the TS generated JS (that IMMO is pretty human friendly ) I don't think it will have better luck reading hand-coded messy JS.

Plus, you always have the TS's source code with the interfaces and more natural OOP manners.

the benefits of incorporating OOP and structure outweight the cons(if there is any).

IDE support is great (Webstorm , Visual Studio) , you can actually refactor!

And you have scoped lambdas :)

The next iteration EcmaScript will be very much like what is TS today (without optional type saftey and a few niceties).

What is gonna happen if somebody in the 'Js team' jump to ES6 with traceour or whatever other thing, will you care?. You will simply stick to the api provided by the module and work with that.

Interfaces and Generics and washed up no trace of them on the JS side. its *optional design time help.

And regarding the budling and minification thing, it will be the same as with JS , no difference , + you could jump one step with TS copilling everything to 1 outputfile

IMMO the solution is level-up , modularize(serioulsy), tests(very helpful if written with self documenting puprposes) and Documentation.

Answer
  • What will be the JavaScript shape of the TypeScript API that extensively uses generics, class hierarchies, interfaces?

Typescript erases type information during compilation, including generic parameters. This means that you just omit the type parameters in your javascript.

  • Are there any issues with bundling, minification, AMD?

No.

  • Is it possible to have the basic Angular controller written in TypeScript and the other JavaScript Angular controller that inherits the functionality from it? What will be the caveats?

Yes, it's possible. There are no caveats.

General Solution:

In general, there is a simple solution for any interoperability concern between typescript and javascript. By the time the interoperating happens, the typescript has all been compiled to javascript. So if you're worried about how to consume typescript, just compile it to javascript. Then you are interoperating with javascript.

Answer

This actually not all too complicated. . . the first thing you have to understand is that the component is created as an object by angular, and it contains all the data, components, objects and stuff from your api's so you can't just go have JavaScript make a new one, it will be empty and won't actually have your form data in it.

In order to remedy this, you need to add an asset to your site, a simple file with one variable in it is fine, then add it to your app, then import it and set it in your init

i've outlined how you import a JS variable into angular below, but here's a link with a bit more detail:
How to call JavaScript functions from Typescript in Angular 5?

so add the js file containing:

var formComponent = null;

then add it to your app (angular.json)

"scripts": [
    "src/assets/js/formScripting.js"
]

then import it to your component right under your "imports"

declare var formComponent: any;

then assign your object on your init and destroy

ngOnInit() {
    formComponent = this; 
}

ngOnDestroy(): any {
    formComponent = null;
}


//a function in your class that you want to call for test purposes
doAngularThing() {
    console.log('Typescript called from JS:')
}

from that point on, in ANY javascript function all you have to do is call:

formComponent.doAngularThing();

since the formComponent object was assigned to this, it's a pointer to the angular object that loaded your compoonent

Tags

Recent Questions

Top Questions

Home Tags Terms of Service Privacy Policy DMCA Contact Us

©2020 All rights reserved.