Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Angular 4.x in the Renderer #152

Open
platosha opened this issue May 19, 2017 · 10 comments
Open

Support Angular 4.x in the Renderer #152

platosha opened this issue May 19, 2017 · 10 comments

Comments

@platosha
Copy link
Owner

platosha commented May 19, 2017

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.

@platosha platosha changed the title Support Angular 4.x Support Angular 4.x in the Renderer May 19, 2017
@BorntraegerMarc
Copy link
Collaborator

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?

@platosha
Copy link
Owner Author

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.

@BorntraegerMarc
Copy link
Collaborator

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?

@platosha
Copy link
Owner Author

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.

@BorntraegerMarc
Copy link
Collaborator

@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...

@platosha
Copy link
Owner Author

@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.

@jay8t6
Copy link

jay8t6 commented Jul 5, 2017

Are there any solutions out there that would let us use Polymer 1.x elements on a Angular 4 app?

@platosha
Copy link
Owner Author

platosha commented Jul 6, 2017

@jay8t6 I’m not aware of any. It’s probably best to use Polymer 2.

@jay8t6
Copy link

jay8t6 commented Jul 6, 2017

@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.

@platosha
Copy link
Owner Author

platosha commented Jul 6, 2017

@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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants