Open platosha opened 7 years ago
You sure that you want to implement 4.0 support? I see this library more for Angular 2.X support... Or is the goal to achieve Angular + Polymer 1.X support?
Why not? This should be pretty straightforward to do. And yes, it would allow smoother Angular upgrades for those who use Polymer 1.x elements.
The essential goal is to support latest Angular and Polymer with smooth migration between major releases, when possible.
I am not completely sure if we want to support Polymer 2.x with the renderer though. Remains to be seen if we want to put more features/emphasis on the Renderer or not.
With the firsr part I completely agree - but why do you want to build a library doing essentially the same as https://github.com/hotforfeature/origami?
Good question. I don’t have much reasoning behind, except for serving the users who need this library to be maintained and upgraded.
At the same time, I was expecting that for Polymer 2 we can drop some glue code from angular-polymer, making maintenance easier. Not so sure anymore about it, though.
@platosha as I see this library it would be more for angular 2+ and polymer 1.X support. Not really polymer 2+ as that part is already solved (quite nicely, actually). My suggestion would be to focus purely on polymer 1 support and get it to 100%...
I think there are still quite a few things missing like AoT support, etc.
But that is just my opinion...
@BorntraegerMarc Agree. I do not say that we don’t have to fix missing things, like AoT support. I still consider these issues as first priority to solve.
Are there any solutions out there that would let us use Polymer 1.x elements on a Angular 4 app?
@jay8t6 I’m not aware of any. It’s probably best to use Polymer 2.
@platosha thanks for the response. For now, I just want to render the polymer element in an angular 4 app, and set a couple properties, all of the logic is written within the polymer element. is that possible at least? we have too many 1.x elements to convert to 2.
@jay8t6 on a very basic level, it will work without extra libraries/support. It is very limited though.
Basically, Polymer would not be able to track any children of Polymer elements defined in Angular templates. Polymer elements with zero children should work almost fine.
Same with data, for two-way bindings you’ll have to use Polymer’s change events, [(bananabox)] syntax won’t propagate changes from Polymer elements. And so on...
The Renderer APIs have changed in Angular 4, so we have to update Polymer Renderer accordingly.
AFAIK It should be possible to implement the new renderer APIs without breaking compatibility with Angular 2.x.