From "What's Next for Polymer (Polymer Summit 2017)" https://www.youtube.com/watch?v=JH6jEcLxJEI&t=7s at 16:31 of the presentation:
"And if you're using Hybrid mode, don't worry, Polymer 3.0 is going to work with that too."
Could you please provide an example of how to extend an application that e.g. uses <template is="dom-bind"> and <template is="dom-repeat"> to work with Polymer 1.x components so that it can use a Polymer 3.0 component inside those templates?
The hybrid mode slide just meant you would be able to use hybrid syntax in 3.x elements
You still need to move from 1.x to hybrid and then use modulizer for conversion.
Just to make sure I understand what you are saying:
Is that correct?
I will need to run my 1.x application code through 'modularizer' in order to use a 3.x element
Yes.
I will not need to convert any existing 1.x elements to 3.x if I am running Polymer 1.9.x or whatever lands as the hybrid mode version of Polymer
You can stick to 1.9 and would be able to use 2.0 hybrid elements, but not 3.0
the version of Polymer that supports this hybrid mode will satisfy all references to polymer.html from 1.x elements and polymer.js from the application and any 3.x elements
2.0 elements written in hybrid syntax can be used with 1.9 but have to be modulized for 3.0
in hybrid mode, 1.x components will be referenced using
How do you imagine using ES modules and HTML imports at the same time? That would cause a mess.
/cc @FredKSchott please correct me if I'm wrong.
BTW, any ETA for Chrome to deprecate HTML imports and v0 CE implementation?
OK, thanks for your reply.
What this means to me is:
(BTW, re: "_How do you imagine using ES modules and HTML imports at the same time? That would cause a mess._", that was actually the reason I started this thread in the first place. I can't imagine it working at all.)
@brian-cruickshank it was announced that by the end of the year polymer-modulizer should be able to conevrt whole apps.
This is not an option if you use native elements built with v0 specs, e. g. app-router and pushstate-anchor.
polymer-modulizer doesn't support importHref and there is no indication that any plan exists how to preserve importHref. So I don't think that 1.x and 3.x elements can co-exist in the foreseeable future at all.
polymer-modulizer isn't quite ready to have a complete turn-key solution for migrating a hybrid application to 3.x, but we've already been using it to create the 3.0-preview branches of our elements and polymer 100% automatically.
There's still a few issues around porting tests, and a replacement for importHref, but the 2.x and hybrid to 3.x conversion is much more mechanical than the 1.x to 2.x conversion because no underlying Web Components specifications have changed.
It should not take too long to start having explanatory examples of upgrading a single element, a group of elements, and an application in the near future.
@brian-cruickshank I think the terminology around "hybrid mode/hybrid elements" is confusing. So, apologies there.
We use "hybrid element" specifically to mean an element that can run in 1.x and 2.x, which uses the legacy Polymer() factory method and a compatible subset of the 1.x and 2.x APIs.
I think Fred was trying to answer the question, "Will you support the hybrid syntax, or just the 2.x class-based syntax." And the answer is, you can keep using the hybrid syntax, you don't need to change to 2.x class-based syntax to use 3.0. But a 3.0 element won't run in 2.x or 1.x.
(You might theoretically be able to use 3.x and 2.x elements on the same page, since 3.x doesn't create globals like window.Polymer. But it may be more work than it's worth. Since 1.x uses the older v0 polyfills, I don't think 1.x and 3.x on the same page would be workable.)
To make things more clear, I've been trying to separate the terms "hybrid mode" from "legacy syntax".
Hybrid mode is an element that can run in either 1.x or 2.x. To do this it in part has to use the legacy syntax.
Legacy syntax is simply thePolymer() function. It's possibly to write a Polymer 2.0 element in legacy syntax that's _not_ hybrid because it uses some newer 2.0 APIs.
polymer-modulizer only converts 2.0 elements, but it does support the legacy syntax. So it supports hybrid elements because they are valid 2.0 elements. Modulizer doesn't support Polymer 1.x, because 1.x isn't organized in a way that's amenable to auto-translating to JS modules.
FWIW, this is what the Polymer team told the community about Hybrid Mode:
From Taylor Savage's Opening Keynote (Polymer Summit 2016) at 16:02
"And of course we don't want to leave Polymer 1.0 users, these many big large Polymer 1.0 users, in the dust, so Polymer 2.0 comes with a near-seamless backwards compatibility layer, making it dead-simple to upgrade an element from Polymer 1.0 to 2.0. And critically, Polymer 2.0 also lets you build elements in what we call 'hybrid mode' and what Hybrid Mode means is that the very same element will work under Polymer 1.0 or Polymer 2.0 with a compatibility layer. And this allows you to incrementally upgrade your project, one component at a time, so I'll show you what that would look like:
In a typical 1.0 to 2.0 transition, you would have your entire application and all the components all built on 1.0 and, stop the presses, suddenly we have to go back to the drawing board, rebuild every single element so that it works in 2.0, and weeks or maybe months or maybe even years later we finally finish this transition and we can start again 2.0 fresh, and this is terrible, this is a bummer, especially if you have hundreds or thousands of components to upgrade.
So with Hybrid mode, you can now incrementally upgrade your project in place. So again, Hybrid mode means that the very same element definition can run using Polymer 1.0 OR Polymer 2.0"
Clearly, Polymer 3.0 elements do not support this definition of Hybrid mode since they cannot run in either Polymer 1.0 or Polymer 2.0. I think Justin's idea of using a term like "legacy syntax" instead of Hybrid mode would be helpful when talking about Polymer 3 elements.
As things stand, we're pretty much at risk of being "left in the dust" at this point. It was difficult to justify the 5 weeks it took to migrate from 0.5 to 1.0, and it's looking like another major effort going from 1.9 to 3.0.
From the Polymer 2.0 upgrade guide:
"The Polymer team plans to release a Polymer Upgrade tool to automatically perform a number of the changes required to upgrade 1.x elements to either hybrid or class-based style. The remaining changes require either manual code changes, testing, or both to ensure that your element operates the same in 2.0 as it did in 1.x. The upgrade tool is not available at this time."
Are there any plans to make this upgrade tool available?
it's looking like another major effort going from 1.9 to 3.0.
I wouldn't go from 1.9 to 3.0. Go from 1.9 to 2.0, which you can do incrementally, then auto-convert to 3.0.
Are there any plans to make this upgrade tool available?
@rictic is working on bring internal conversion helpers to an external tool. The manual changes are very simple though.
@justinfagnani
Re:
@rictic is working on bring internal conversion helpers to an external tool.
That would be much appreciated. Thank you!
One question regarding 3.0 and the 2.0 to 3.0 auto-conversion for application code (not elements): can applications retain the template code in html (e.g. keep the
A lot of my concerns over the direction of 3.0 would be addressed if applications were able to keep the template tags and element tags in html.... It would allow 'assemblers' to retain all of the benefits of Polymer's declarative approach, and it avoids having to insert weirdness into the html to identify where to inject the template strings. The whole move to ES6 modules for components I can understand and appreciate, but I'm concerned that forcing applications to render template strings into the application DOM in order to use Polymer elements will create a lot of potential problems.
@brian-cruickshank HTML files that serve as entrypoints, such as index.html, would use the same <dom-bind> and <template is="dom-repeat"> tags that they use in 2.x.
HTML imports would be converted to JavaScript modules. Elements in those modules have their top-level templates converted to strings (a feature which is also supported in 2.0).
Inside that string, you'd specify your template contents exactly the same way you did in 2.0, including <template is="dom-repeat">, <template is="dom-if">. For example:
static get template() {
return `<template is="dom-repeat" items="{{myItems}}">
<div>[[item.name]]</div>
</template>`
Hope that clarifies the situation a bit.
@arthurevans - thank you! That does help clarify things a lot.
Just to make sure I fully understand this: the only changes that will be required for html files that serve as entrypoints would be to replace _<link rel="import" href="... .html">_ with _<script type="module" src="... .js"></script>_ and rework javascript that uses importHref - is that accurate? All of the existing template stamping APIs, lifecycle events, etc. are unchanged?
@brian-cruickshank Sorry for the late response, but yes you are correct. The API remains, but Polymer 3 will use a different loading mechanism: ES modules.
Hopefully the confusion has cleared up regarding the terms "hybrid mode" and "legacy syntax", as well as the differences in terms of loading Polymer 2 and 3. Therefore I am closing this issue. Feel free to reopen if you are still uncertain about any aspect.
Hi am new to polymer,
is it possible to update polymer 1.x project directly to polymer 3.x version ?
i need you help on SHOP demo, some days , i will dis my question in detail.