Abandon TypeScript?

[benlesh]

Because of the modular nature of this library. I'm starting to feel like maybe TypeScript isn't a natural fit for what we're doing.

Why TypeScript to begin with?

If we were to support TypeScript typings, it made sense to "transpile down". There have been other benefits to the project over type as well, but the main thing was for the automatic generation of typings information for our partners on the Angular team, and for the larger community of TypeScript developers that care about high-quality typings information. The idea was that be using TypeScript, it would generate the best .d.ts files for us.

Issues

Frequently we're forced to jump through hoops just to generate proper .d.ts files. For example: We have to add property "stubs" for methods on Observable we wanted to be optional for modularity's sake. That actually causes other issues where we need to monkey with the prototype of ScalarObservable if we want to override those methods, because TypeScript can't handle reconciling non-existent instance properties that could contain functions and prototype "methods", when there's no real distinction in JavaScript between a "method" on a prototype, and a property key on a prototype that has a function in it.

The goal was to have operators that end users could simply import into their own Observable and decorate the prototype thereof. Basically what we're doing in our Rx.ts file, only specific for their own output purposes. Even better, they could just use ES7 function bind. TypeScript makes the former unergonomic and the latter completely impossible (because it doesn't support function bind).

We also have way too many cases where we're forced to cast as <any> in our app just to make things work that should "just work" in JavaScript. I suppose in a lot of cases, we could use an Interface instead, but it's generally not something that is going to help the public API so it's probably not worth doing anything but the <any> cast. Still, each time we're force to do that what we're really doing is working-around TypeScript.

The good of TypeScript

TypeScript has helped us find and avoid bugs. I've seen it. Places were we were passing the wrong type to the wrong place, etc.

TypeScript makes it really unergonomic to create polymorphic functions. This is a very good thing, IMO, because polymorphic functions should be avoided for performance reasons, and for the reasonability of the functions that you're writing.

Having type information in our code to statically analyze will provide us with opportunities to do smarter things with our minification processes in the future this is something I know our friends at Angular are working on (per @jeffbcross). It may also provide some ability to do more granular "tree-shaking" at some point.

Alternatives

1. Babel/ES6 port our generated ES6 code over to be our src and maintain .d.ts files by hand. This might actually be less work than dealing with TypeScript because we'll only be typing the type information for the operators one time, and we only really have to maintain it for what is our public API.
2. ES5 plain, old, ES5 with CJS. Their are a lot of sucky things about this approach. One is that if we wanted to support ES6 modules, we would need to do some sort of transpile in what I would normally consider to be "the opposite direction". We'd also be missing a lot of really nice features.

Thoughts?

The timeline for this would be totally indeterminate; However, I'd want to make the move prior to release if we made a move at all.

[benlesh]

Also, I'll admit that #468 was, at least in part, stemming from the fact that there is some ugliness around our modular operator structure in TypeScript.

[staltz]

I actually think it was a good idea to build it with TypeScript. For the performance argument (avoiding polymorphism) and for the reliability argument (Dynamic typing is really not a sane idea for large codebases, a lot of smart developers advocate types for large projects).

Still, each time we're force to do that what we're really doing is working-around TypeScript.

If you just want to get stuff done and get types out of your way, then there isn't anything better than dynamically typed JavaScript. That's the main benefit of dynamic typing: getting out of the developer's way. Types are there to guide the programmer. We shouldn't default to putting <any> whenever "TypeScript complains". Instead we need to stop and actually think what possible types that thing can assume. The benefit will be greater in the long run, and that's what this project is for.

Babel/ES6 port our generated ES6 code over to be our src and maintain .d.ts files by hand.

Either way, we'll have to maintain things by hand, be that .d.ts or property stubs in Rx.ts. And I'd say now is quite late to migrate to ES6.

ES5 plain, old, ES5 with CJS.

Definitely not this option. This library targets the future, not the past.

[staltz]

PS:

they could just use ES7 function bind

ES7 function bind is a Stage 0 feature, we shouldn't make any assumption on its availability.

[benlesh]

ES7 function bind is a Stage 0 feature, we shouldn't make any assumption on its availability.

SHUT YOUR STINKIN' MOUTH @staltz! (I love that feature) 😛

[staltz]

[mattpodwysocki]

Yeah, I kept away from TypeScript just because it kept the number of contributions lower in terms of contributions because the barrier to entry was a bit higher. But to each their own...

[RyanCavanaugh]

We're looking at this and want to make sure we understand the scenarios before making any recommendations.

For example: We have to add property "stubs" for methods on Observable we wanted to be optional for modularity's sake.

My initial take on this is that you should be using declaration merging to add things to the Observable type as they "become available" via imports (but more on that later).

That actually causes other issues where we need to monkey with the prototype of ScalarObservable if we want to override those methods

This is the same link as before (intended?) so I don't quite have context on what this means

because TypeScript can't handle reconciling non-existent instance properties that could contain functions and prototype "methods"

TypeScript doesn't distinguish these two cases, which I would think would make things easier rather than harder.

The goal was to have operators that end users could simply import into their own Observable and decorate the prototype thereof.

Several questions here -- "their own Observable" means a subclass of Observable? Or is the intent that end users should be modifying Observable.prototype from user code ("decorate" === mutate, or decorator?).

Just thinking concretely, in your ideal modular world, user code would look something like this?

// Core import
import * as rx from 'rx';
// Add the operators I need
import * as forEach from 'rx-forEach';
rx.Observable.prototype.forEach = forEach;

// Proceed to user code

Possibly the big missing piece here is the ability augment global types from within a module.

[benlesh]

This is the same link as before (intended?) so I don't quite have context on what this means

@RyanCavanaugh ... oops. I meant this link

Several questions here -- "their own Observable" means a subclass of Observable? Or is the intent that end users should be modifying Observable.prototype from user code ("decorate" === mutate, or decorator?).

Yes, that's part of the original design. Mostly to support dialects that don't have ES7 function bind.

Just thinking concretely, in your ideal modular world, user code would look something like this?

Not really. In my ideal world it looks like this:

import { Observable } from 'rx';
import map from 'rx-map';
import filter form 'rx-filter';

const source = Observable.of(1,2,3,4,5,6,7);
const mapped = source::filter(x => x % 2 === 0)::map(x => x + '!!!');

... but unfortunately, we have needs in the non-transpiled world too, in which prototype decoration is what we're stuck with. :\

[benlesh]

@RyanCavanaugh .... One big, near-term issue for the Angular team around Rx, is: How do they include the operators people will need without bloating their byte-count? This is one of the reasons the modular design exists.

So, in a world where we need type information for those methods for TypeScript users, I need to export a .d.ts file that shows all possible core operators on Observable if they're there.

Right now I'm just defaulting to adding all "core" operators as stubs to Observable.

[RyanCavanaugh]

What does the ideal world, absent the ES7 bind operator, look like?

[benlesh]

@RyanCavanaugh I think I'd like it if the TypeScript compiler didn't complain that I'm adding prototype methods to a subclass when the superclass's instance properties of the same name are undefined. Alternatively, I'd love it if there was a way to tack on type information in the .d.ts for properties that may or may not be there.

[RyanCavanaugh]

Alternatively, I'd love it if there was a way to tack on type information in the .d.ts for properties that may or may not be there.

Either I'm misunderstanding the scenario, or that's already supported:
https://github.com/RyanCavanaugh/TryRx/blob/master/sample.ts
https://github.com/RyanCavanaugh/TryRx/blob/master/augmentations.d.ts

The one piece that would make the whole story work 100% smoothly is if importing a module could cause side effects to types in the global namespace. In that setup, using the example above, you'd have e.g. a module even that had a type-system side effect of augmenting the global type Observable That's not currently alowed, but it's something we've discussed.

[benlesh]

I guess, I'm too new to this... is augmentations.d.ts some idiomatic way of altering the type information? How does the type system know to pick that up?