Question about typescript style of implementation.

[vance]

I have a medium-sized project (~15-20k SLOC). It was coded under a tight deadline so there's hardly any tests. Now the the initial deadline to demo it is passed, we can prep it for production. As a first step, rather than write tests for everything, I think there's a lot to be gained by typscripting it first, then adding tests to the most core features as time allows.

I'm at a loss for what style is the best approach. I'm comparing your project to this one. Specifically, this project template seems to go much farther extremes in using the typescript features to rigidify the app.

As a starting point, looking at their app.js, it is far more rigorous. It has functions to register every controller, service, directive etc. This may seem like overkill, but it allows us to use the module pattern in the controllers, as such:

module app.controllers {
    export class MyController implements IController {
        constructor (private $scope, private myService) {
            $scope.message = myService.someMethod();
        }
    }
}

So What i'm asking is, is santialbo's complexity really necessary? I mean, I like the idea of being very strict everywhere, but on the other hand, I have a lot of js files to convert. I kind of like your hybrid approach where we kind of leave the angulary-parts in vanilla js, but add some type definitions for the $scope and models. I mean, there's not a whole lot to a controller or a directive that really needs type definitions. I'd think it's mainly models and such you want to be sure you can refactor easily.

todomvc.controller('TodoCtrl', function TodoCtrl($scope:TodoCtrlScope, $routeParams:TodoCtrlRouteParams, todoStorage:TodoStorage, filterFilter) {
    var todos = $scope.todos = todoStorage.get();
    ...

I just don't want to shoot my self in the foot and not get the "strictness" I crave. Maybe this is a weird question, but I'm a TS noob. In santialbo's example app.js do I need those module registrations to declare controllers as he does? If I understand correctly, his example app tries to make first-class typescript objects/classes/modules out of the boilerplate angular objects, is this correct?

great intro vid, btw.

[seanhess]

So I'm at a bar, and not in the mood to look at the other project right now, but I think there's a high level principle that could help here.

Don't bite off more than you can chew.

That's what is so cool about gradual typing and type inference in the first place! You don't have to "convert" your project in one horrible, get permission from management, 2 week step. You can just start now, in some small way, and keep improving things every week.

I think this applies to more than just adding types. I'm a big believer in constantly refactoring, investing, improving a code base over time rather than all at once. Basically if you have to ask permission from stakeholders you are doing it wrong :)

So I guess my advice is: just start. Add typescript to your build process. Use it in a few places that are obviously useful. Then make sure every week you add more. Your experience and knowledge will grow along with the process and you can decide what is right for your project.

I think it's very wise to type before testing. Much better return on investment.

Cheers! I can take a closer look on Monday if you like.

On Friday, November 13, 2015, ForeverScape notifications@github.com wrote:

I have a medium-sized project (~15-20k SLOC). It was coded under a tight deadline so there's hardly any tests. Now the the initial deadline to demo it is passed, we can prep it for production. As a first step, rather than write tests for everything, I think there's a lot to be gained by typscripting it first, then adding tests to the most core features as time allows.

I'm at a loss for what style is the best approach. I'm comparing your project to this one https://github.com/santialbo/AngularJS-TypeScript-Project-Template. Specifically, this project template seems to go much farther extremes in using the typescript features to rigidify the app.

As a starting point, looking at their app.js https://github.com/santialbo/AngularJS-TypeScript-Project-Template/blob/master/src/app.ts, it is far more rigorous. It has functions to register every controller, service, directive etc. This may seem like overkill, but it allows us to use the module pattern in the controllers, as such:

module app.controllers { export class MyController implements IController { constructor (private $scope, private myService) { $scope.message = myService.someMethod(); } } }

So What i'm asking is, is santialbo's complexity really necessary? I mean, I like the idea of being very strict everywhere, but on the other hand, I have a lot of js files to convert. I kind of like your hybrid approach where we kind of leave the angulary-parts in vanilla js, but add some type definitions for the $scope

todomvc.controller('TodoCtrl', function TodoCtrl($scope:TodoCtrlScope, $routeParams:TodoCtrlRouteParams, todoStorage:TodoStorage, filterFilter) { var todos = $scope.todos = todoStorage.get(); ...

I just don't want to shoot my self in the foot and not get the "strictness" I crave. Maybe this is a weird question, but I'm a TS noob. In santialbo's example app.js https://github.com/santialbo/AngularJS-TypeScript-Project-Template/blob/master/src/app.ts do I need those module registrations to declare controllers as he does? If I understand correctly, his example app tries to make first-class typescript objects/classes/modules out of the boilerplate angular objects, is this correct?

great intro vid https://www.youtube.com/watch?v=u6TeBM_SC8w, btw.

— Reply to this email directly or view it on GitHub https://github.com/seanhess/angularjs-typescript/issues/4.

[seanhess]

Oh, also, I'm a consultant, and I often spend a week or two with companies like yours who want their project to be done right. Let me know if that would make sense for you guys. It can be a huge time saver since getting things done well can save time across multiple programmers.

On Friday, November 13, 2015, Sean Clark Hess seanhess@gmail.com wrote:

So I'm at a bar, and not in the mood to look at the other project right now, but I think there's a high level principle that could help here.

Don't bite off more than you can chew.

That's what is so cool about gradual typing and type inference in the first place! You don't have to "convert" your project in one horrible, get permission from management, 2 week step. You can just start now, in some small way, and keep improving things every week.

I think this applies to more than just adding types. I'm a big believer in constantly refactoring, investing, improving a code base over time rather than all at once. Basically if you have to ask permission from stakeholders you are doing it wrong :)

So I guess my advice is: just start. Add typescript to your build process. Use it in a few places that are obviously useful. Then make sure every week you add more. Your experience and knowledge will grow along with the process and you can decide what is right for your project.

I think it's very wise to type before testing. Much better return on investment.

Cheers! I can take a closer look on Monday if you like.

On Friday, November 13, 2015, ForeverScape <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

I have a medium-sized project (~15-20k SLOC). It was coded under a tight deadline so there's hardly any tests. Now the the initial deadline to demo it is passed, we can prep it for production. As a first step, rather than write tests for everything, I think there's a lot to be gained by typscripting it first, then adding tests to the most core features as time allows.

I'm at a loss for what style is the best approach. I'm comparing your project to this one https://github.com/santialbo/AngularJS-TypeScript-Project-Template. Specifically, this project template seems to go much farther extremes in using the typescript features to rigidify the app.

As a starting point, looking at their app.js https://github.com/santialbo/AngularJS-TypeScript-Project-Template/blob/master/src/app.ts, it is far more rigorous. It has functions to register every controller, service, directive etc. This may seem like overkill, but it allows us to use the module pattern in the controllers, as such:

module app.controllers { export class MyController implements IController { constructor (private $scope, private myService) { $scope.message = myService.someMethod(); } } }

So What i'm asking is, is santialbo's complexity really necessary? I mean, I like the idea of being very strict everywhere, but on the other hand, I have a lot of js files to convert. I kind of like your hybrid approach where we kind of leave the angulary-parts in vanilla js, but add some type definitions for the $scope

todomvc.controller('TodoCtrl', function TodoCtrl($scope:TodoCtrlScope, $routeParams:TodoCtrlRouteParams, todoStorage:TodoStorage, filterFilter) { var todos = $scope.todos = todoStorage.get(); ...

I just don't want to shoot my self in the foot and not get the "strictness" I crave. Maybe this is a weird question, but I'm a TS noob. In santialbo's example app.js https://github.com/santialbo/AngularJS-TypeScript-Project-Template/blob/master/src/app.ts do I need those module registrations to declare controllers as he does? If I understand correctly, his example app tries to make first-class typescript objects/classes/modules out of the boilerplate angular objects, is this correct?

great intro vid https://www.youtube.com/watch?v=u6TeBM_SC8w, btw.

— Reply to this email directly or view it on GitHub https://github.com/seanhess/angularjs-typescript/issues/4.

[vance]

Thanks! I already use typescript on a separate project on a node server. It is much more straightforward with node than with angular. I've already integrated TS with my build process... and, yes, I plan on starting with just typing my models and business logic, the controllers and views can settle-in to TS as needed. I have the process, I guess my main question is about the specific huge difference in actual implementation. Both seem like very valid approaches, but are night-and-day. It seems like the other approach is more all or nothing, as it expects every controller etc. to register in a seemingly TS-specific way.

[vance]

Yeah, upon further consideration, it would seam that your implementation, while "within typescript" it does not actually structure controllers etc. as typescript classes, so it's the "half-way" implementation by using an Interface to stub the class instead of making it an actual class. I think I would prefer to do it this way (so we get TS's syntactical cleanliness in the actual controller as well).

module app.controllers {
    export class TSDemoController {

        playListService: angularWithTS.Interfaces.IPlaylistService;
        static $inject = ["angularWithTS.Services.PlayListService"];
        constructor(playListService: angularWithTS.Interfaces.IPlaylistService) {

            this.playListService = playListService;
        }
        favorites: Array<angularWithTS.Interfaces.ITrack>;

        getFavourites = () => {
            this.favorites = this.playListService.getPlayList();
        }
    }

    angular.module("app").controller("app.controllers.tsDemoController", TSDemoController);
} 

Sorry if this is tangential, talking aloud about such things helps to solidify one's thoughts. Thanks for sharing this angular-typescript material though, it is helpful to see.

[seanhess]

Cool, go for it!

Just make sure to concentrate on how many errors your implementation will catch. My brief look at the example wasn't typing the scope, which for a controller would be the largest source of errors.

Also, the angular module pattern is redundant with CommonJS.

Good luck! ~sean

On Tue, Nov 17, 2015 at 12:36 PM, ForeverScape notifications@github.com wrote:

Yeah, upon further consideration, it would seam that your implementation, while "within typescript" it does not actually structure controllers etc. as typescript classes, so it's the "half-way" implementation by using an Interface to stub the class instead of making it an actual class. I think I would prefer to do it this way (so we get TS's syntactical cleanliness in the actual controller as well).

module app.controllers { export class TSDemoController {

    playListService: angularWithTS.Interfaces.IPlaylistService;
    static $inject = ["angularWithTS.Services.PlayListService"];
    constructor(playListService: angularWithTS.Interfaces.IPlaylistService) {

        this.playListService = playListService;
    }
    favorites: Array<angularWithTS.Interfaces.ITrack>;

    getFavourites = () => {
        this.favorites = this.playListService.getPlayList();
    }
}

angular.module("angularWithTS").controller("angularWithTS.controllers.tsDemoController", TSDemoController);

}

Sorry if this is tangential, talking aloud about such things helps to solidify one's thoughts. Thanks for sharing this angular-typescript material though, it is helpful to see.

— Reply to this email directly or view it on GitHub https://github.com/seanhess/angularjs-typescript/issues/4#issuecomment-157482062 .

[vance]

Hey thanks for the CommonJS tip. I had been meaning to move to browserify. Currently i've been using the old boilerplate-heavy IIFE function style. Switching would really help clean that up. Well, a couple days into moving the project over, I figured out how to convert angular constants to static class properties, overall the process is about what I had expected, only one really wacky bug (you'd probably think is crazy).

-vance