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
#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
#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
#4 (comment)
.

[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