Upgrading from earlier version - ES6 classes

[mokargas]

Hey there,

I've recently upgraded my dev stack from a 3.x version of the generator to the new 4.0.1. I think the new changes (to me) are broadly good ones, except for ES6 Classes. My reasoning is roughly encapsulated in https://github.com/joshburgess/not-awesome-es6-classes and beyond.

My question is, is there any way to change the component generation from automatically generating ES6 class boilerplate by default?

• [X] I understand that GitHub issues are not for tech support, but for questions specific to this generator, bug reports, and feature requests.

Item	Version
generator-angular-fullstack	4.0.1
Node	4.4.7
npm	3.10.5
Operating System	OS X 10

Item	Answer
Transpiler	Babel / TypeScript
Markup	HTML / Pug
CSS	CSS / LESS / SCSS / Stylus
Router	ngRoute / ui-router
Client Tests	Jasmine / Mocha
DB	MongoDB / SQL
Auth	Y / N
etc	etc

[Koslun]

I think the new changes (to me) are broadly good ones, except for ES6 Classes. My reasoning is roughly encapsulated in https://github.com/joshburgess/not-awesome-es6-classes and beyond.

The generator is moving to Angular 2 soonish and given that classes are part of the API or at least best practice for using Angular 2 I don't see us going away from ES6 classes for components and services.

Reading the first level of the link, and just previous knowledge, I think I can somewhat understand that you can reason around not using classes but I've not yet been convinced classes are never the answer. Just two different programming paradigms that can both work. Think the Angular 2 solution with classes work just fine, given the use of decorators. Think it's easy enough to grasp and don't really see the point in trying to turn them into functions as I think they make perfect sense as classes. So though I can in principle understand some kind of functional-purity discussion around Javascript I don't see the benefit in Angular 2 at least.

My question is, is there any way to change the component generation from automatically generating ES6 class boilerplate by default?

Think it would either require an additional template or complicate the current template quite a bit with quite a lot of ejs if-block. If only done for the component generator it might be maintainable but doing it for all of the client code would be a lot of work unless you could do it automatically somehow with ejs it would become a lot of work to maintain. At best it'd be if you could do some kind of automatic conversion from class to functions. I.e. that we could continue developing using classes but that through some tool we could get regular ES5 functions. Don't know that either Babel or Typescript can output code pretty enough for that task but imagine that you could theoretically just look at the output of Babel or Typescript and code using that. Though you would lose everything else in ES6/Typescript too.

So I would say there is a way but it would slow us down and hold us back from upgrading to Angular 2 in particular. So I doubt we would so we can get Angular 2, Gulp 4, TypeScript 2, Webpack 2 and Angular 2 specific features faster. Know that @Awk34 (the core contributor) has previously voiced disdain for creating multiple templates too.

[mokargas]

Hi @Koslun, thank you very much for the backgrounding on the decisions around Angular 2, ES6 classes and the future of the generator. It makes more sense to me now, even though it does mean writing JS in a certain way if I want consistency amongst my components.

To be honest it is more of a "philosophical" question in the JS community, broadly functional programming vs pseudo-OOP. In my case I am used to, and fastest at, writing JS in terms of object composition. In my experience, class based language paradigms usually run into the "fragile base-class" problem (amongst others) at some point, which is a real worry when maintaining moderately sized apps or complex components.

Anyway, thankyou for the answer and I'll try align our development accordingly.

[Koslun]

@mokargas Yeah have thought a bit about the functional programming vs pseudo-OOP for JS before with NodeJS setup where I conversely also have come to prefer just using object composition. So can definitely respect that.

Given the use of decorators for Angular 2 classes I however believe you're not completely locked into it. You could do some big base class that a lot of components inherit from but you can also still skip inheritance completely and think you could even directly assign member functions to imported functions. Think that Angular doing the instantiation of the classes also makes it less OOP.

[honkskillet]

So this package is going to eventually be converted to Angular 2? Is there a roadmap for this project?[edit]