Polymer for typescript 1.6 and ES6 classes

[gertcuykens]

Can anybody from the polymer team take a good look at typescript please and make a blog post? Wheatley from polymer slack pointed this out https://github.com/nippur72/PolymerTS But I still think it can be way more improved if polymer was designed form the ground up to be typescript friendly. The sooner somebody study this the better because like it or not js is not made for the heavy lifting single app applications Polymer is aiming at. Just a webshop is difficult enough already to debug in Polymer. Polymer is really nice when everything it is working and you only have to at a component but when its not, it's a living hell to find what is wrong, ask anybody who migrated from 0.5 to 1.0 and forgot something :P

[ebidel]

IMO ES6 is the future and way forward. For example, I'd like to see us support ES6 classes out of the box. Classes work today but with possible caveats.

On Sat, Jul 11, 2015, 7:33 PM Gert Cuykens notifications@github.com wrote:

Can anybody from the polymer team take a good look at typescript please and make a blog post? Wheatley from polymer slack pointed this out https://github.com/nippur72/PolymerTS But I still think it can be way more improved if polymer was designed form the ground up to be typescript friendly. The sooner somebody study this the better because like it or not js is not made for the heavy lifting single app applications Polymer is aiming at. Just a webshop is difficult enough already to debug in Polymer. Polymer is really nice when everything it is working and you only have to at a component but when its not, it's a living hell to find what is wrong, ask anybody who migrated from 0.5 to 1.0 :P

— Reply to this email directly or view it on GitHub https://github.com/Polymer/polymer/issues/2067.

[gertcuykens]

I can't judge ES6 Classes yet but I hope everybody agrees that when I am writing a component in js, the future needs to be this.(and gives me a list of all properties with there type) Or data="{{myvar}}" tels me data is expecting a string not a number. Or myvar isn't defined etc. As far as I know typescript is leading in this part. Maybe create a starterkit TS or ES7 version and see where it leads too? Now that polymer 1.0 is reduced to the bare minimum its time to think about this before it gets more complex and prevent a other 0.5 -> 1.0 migration hell :D

[hourliert]

:+1:

[nippur72]

I agree, we need a Polymer implementation that is class-friendly.

The actual PolymerTS is good but struggles too much to make it typescript friendly and there are some of issues.

Ideally, we could have the same route of Angular2, that is, written in subset of TypeScript and then compiled to TS/JS and Dart.

[gertcuykens]

I vote for what ever it takes and team up with angular and nippur72 on this. Wil it be difficult yep, wil it take time yep, will you need to start over yes, will it be worth it to make polymer type safe, hell yeah! PS You need to vulcanize the code anyway so a compiling step would be no different. Also asked it on stackoverflow to get more inside (deleted fantastic...)

[gertcuykens]

https://github.com/Microsoft/TypeScript/issues/574 You are going to need typescript 1.6

[nippur72]

@gertcuykens we don't need a complete rewrite, but only to change the way objects are registered. Currently we pass a plain javascript object to Polymer(), instead we need to pass an uninstantiated ES6 class, possibly an extension of HTMLElement (soon to be supported in TS1.6).

Indeed the only bottleneck of PolymerTS is during registration: it has to create an instance of the class and then copy its members to the Polymer registration object. A step it's better to avoid.

[gertcuykens]

So basically the request would be to create Polymer and the Polymer Elements like this right?

class Polymer extends HTMLElement {...}
class PaperElement extends Polymer {...}

And after that has been done, type definition files can be created for Polymer and each element right?

[nippur72]

@gertcuykens yes, more precisely elements would extend the already-existing Polymer.Base which in turn is an extension of HTMLElement.

The hard part is make Polymer create elements from classes rather than objects.

Anyway today I gave a quick look at Polymer's source code and it seems to me that it's not so difficult to modify it in order to accept "classes". I will look more into it, trying to make a PR.

[gertcuykens]

@ebidel Are you willing to accept a new classes branch please? You wanted to use ES6 classes anyway in the future :P Then it wil be right in time to make sure Polymer wil fit typescript 1.6 like a glove.

[clintwood]

+1 for ES6! Although TypeScript is great it would be nice to keep in line with standards.

@gertcuykens, I'm using Aerotwist's idea for using ES6 right now which is ok, but proper integration with ES6 classes (extends, properties, methods, static methods, etc) would be awesome and timely since most new frameworks (e.g Aurelia) are rolling out ES6 ready.

[nippur72]

after looking at the source code, I think we need the following:

1. slightly change Polymer.Base object to make it an inheritable ES6 class (actually it can't because it's a simple object with no prototype and some property getters that cause troubles).
2. write a new custom registration function (e.g. Polymer.registerType(className) or similar) that does almost the same thing as Polymer({}) but with avoiding the step:

prototype = Polymer.Base.chainObject(prototype, Polymer.Base);

instead it should use the object passed as argument, without chaining it, because the object would be already an extension of Polymer.Base and HTMLElement.

Note: TypeScript 1.6 it's NOT needed because you don't have to extend HTMLElement, but you extend Polymer.Base and for that a declare class it's enough. You don't even need TypeScript, it can work with just ES6.

[gertcuykens]

@nippur72 thanks @ebidel common lets do this, don't worry I wil not be creating typescript issues here :P

[ebidel]

I'd love to see this happen, but it's not my call. My gut is also that the Polymer team is adverse to adding a required build step to use Polymer elements / Polymer. Until classes are supported everywhere, it's going to be a tough sell.

[gertcuykens]

Ok lets go the vulcanize route then and include a option to apply a ES6 patch that wraps the Polymer.Base and Elements?

[clintwood]

@ebidel, agreed with your ES6 sentiment, however, if the Polymer team stalls on providing at least ES6 support early on this will most likely go out to 3rd party projects which will fall short of the good integration that Polymer team would do as owners of the original source. In other words better to have this done in-house (IMHO). The changes that @nippur72 suggests would at least get us going.

[nippur72]

I made a change in PolymerTS that gets very close to what we are discussing here, perhaps making any mod to Polymer unnecessary.

I crafted a polymer.Base object that is seen as a ES6 class and that is extensible with no payloads (the previous version featured an annoying object-cloning).

So after all changing Polymer is not necessary, since anyway you have to use an additional package to support decorators.

[gertcuykens]

Ok Polymer team, you won this round but prepare for the next, because now we have a nippur72 ES6 tank coming your way :P My first mission is to get the starter kit compiled. @nippur72 I am looking at the sample and test code but it requires visual studio for the web service I think. That part needs to be replaced by gulp, nodejs and visual code reinforcement to defeat the incoming anti ES6 tank shells.

[gertcuykens]

@ebidel INCOMMING ES6 TANK https://github.com/PolymerElements/polymer-starter-kit/pull/266 :P