Closed fat-crienturu closed 6 years ago
Hi @fat-crienturu It's already available for Polymer 3: https://www.npmjs.com/package/@vaadin/vaadin-grid
@tomivirkki Now that Polymer 3 is finalized, are y'all going to up the npm versions to the same as the bower versions?
@moderndeveloperllc Yeah that's the ultimate goal. We're currently on sort of a "beta period". Once ready, we can merge all the p3-preview
branches to master
and unify versioning (only minor version bumps expected).
Do you have an approx ETA for this but any chance?
@moderndeveloperllc Can you please share a working sample polymer 3.0 project using any vaadin component ?
@mmohammad-pk here is the project containing all the free Vaadin components: https://github.com/web-padawan/polymer3-webpack-starter
You can see the demo at https://polymer3-webpack-starter.herokuapp.com
@web-padawan That's a great sample project thanks for sharing! Do you have with polymer 3's lit-elememt/lit-html by any chance?
From the looks of the starter project you posted @mmohammad-pk , the vaadin-button 2.1.0-beta2, is suppose to be Polymer3, but doesn't use LitElement? It uses PolymerElement, which is the Polymer2 base class no?
@aadamsx LitElement is still in a pre-beta stage from what I can tell. It will be quite a bit of time before that goes production. Google still calls it an "experiment", so they may still abandon it for something else before it ever even goes 1.0.
Vaadin is using the same route that Google currently is with Polymer itself and the paper-* elements - use polymer-modulizer
to convert to ES6 Module packages that are published on npm. They have put in quite a bit of work to make sure that their elements are compatible with HTML imports (Polymer 2) and ES6 Module imports (Polymer 3). Very nice for folks like me who are still doing Polymer 2 apps right now.
On Googles Polymer 3 announcement page it notes within that if starting a new project, use LitElement. From my reading LitElement/LitHTML is the new path forward and is 100% a go.
From what I understand, there is a delay on 1.0 until IE11 gets better component compatibility (and update for that browser is in the works AFAIK).
I was just confused as to why there is a polymer3 starter repo (linked above) without actual LitElement base calss is all. This tells me the new components are not actually Polymer3 components.
Anyhow, hopefully LitElement will eventually become the base of vaadin components. I'll wait on adding them to my projects until then. :)
@moderndeveloperllc as far as I know google is 100% committed to lit-element and lit-html as @aadamsx mentioned they recommend to use it for all new greenfield projects and in their github repo they say that they are on the fast-track to get to V1. Also the PWA starter kit uses it.
This tells me the new components are not actually Polymer3 components.
This is incorrect. Think of Polymer 3 as a "classic" library which is still maintained, while LitElement is more or less a complete rewrite, not production ready yet. We are aiming to maintain the high quality components and not going to rewrite everything from scratch until API stabilises.
not production ready yet. We are aiming to maintain the high quality components and not going to rewrite everything from scratch until API stabilises.
While it's true they did a complete rewrite, I don't agree that LitElement's API is not close to production quality yet (strickly in terms of the API). The API is stable, but there may be a few bug fixes until it reaches V1.
If you start on the LitElement (LE) components now, by the time they release V1 (from what I've read that's soon), you'll have at least a few components ready to go!
Rewriting your components in P3 "classic" NOW doesn't make sense to me, simply because this "branch" will eventually be depriciated IMO. Just keep your classic components in P2 and base any new component rewrites on LitElement.
(SIDE NOTE: "classic" in this case I think means, the old branch that may or may not be maintained long term... we can't know for sure. But we do know for sure LE is what will be riffed on from here on out).
I think I'm going to incorporate your vaadin router along with LitElement components for my next buisness venture software. Once you guys migrate to LitElement for any of your components, the startup I built and the new one I'm building would 100% become a paying customer of your charts and all the other components -- they look amazing.
Just my 2-cents.
The API is stable, but there may be a few bug fixes until it reaches V1.
Just a small note: Polymer/lit-element#132 is more or less a complete rewrite of lit-element
itself 😃
I see your point and we will take it into account while thinking of the next generation of Vaadin components. For now, we are working on better LitElement compatibility for grid, dialog and other components currently relying on using <template>
tag for content.
I think the vaadin team has a real opportunity to embrace and be on the forefront of LitElement/LitHTML (Polymer3) and become a mindshare leader in this space with: Blog Post, Videos, a CreateLitElementApp starter kit, Tools/Components (Both Paid/Free), Paid Support of said, speaking engagements, etc.
When future devs search Polymer3/LitElement/LitHTML, your website should be ranked highest.
@web-padawan is very correct in that LitElement should't be considered stable yet, and that Polymer/lit-element#132 is basically a rewrite. But it's based on a lot of experience we have over the past couple of years with this exact style of async rendering, and many of the timing decisions and code patterns in the implementation have been used already. It's not a lot of code and pretty well understood, and we'll be moving to 1.0 very rapidly.
But... I don't think that a future <vaadin-grid>
should tie itself to LitElement, any more than any other template system. Unless it's taking specific advantage of lit-html features, it should try to work with Polymer, LitElement, Stencil, etc., etc...
We've also been working on container elements that are much more base-class/template-system agnostic, like <virtual-scroller>
: https://github.com/valdrinkoshi/virtual-scroller
If you can't assume that the user of the container will provide a <template>
that uses Polymer syntax, then you need a more general JS-callback facility to populate items. <virtual-scroller>
does this and provides example hooks for a couple of template systems. It's a good pattern to follow, IMO.
I think I'm going to incorporate your vaadin router along with LitElement components for my next buisness venture software. Once you guys migrate to LitElement for any of your components, the startup I built and the new one I'm building would 100% become a paying customer of your charts and all the other components -- they look amazing.
@aadamsx can you elaborate as to why you think that?
@justinfagnani thanks for your feedback in this issue. Apart from the <virtual-scroller>
which is being tested by @tomivirkki in his prototyping, we are looking into following topics:
possibilities of theming support with lit-element
, to get it working with vaadin-themable-mixin
rendering of the overlays using content teleportation as it is done by vaadin-overlay and components depending on it.
Having these 3 challenges solved, I assume updating the rest of components (e.g. button, checkbox, text-field etc) should be pretty much straightforward.
@macjuan
I'd like to change out my existing SaaS UI for many reasons I won't get into here. I'm also looking at building another SaaS starting in the next few months.
As I do for most all my personal business projects, I'm taking the lay of the land tech wise while I'm gearing up. ATM I think I've settled on:
MongoDB + Nodejs + GraphQL (Apollo Server) + Express (Middleware) + Apollo Client (Cache/Muts/Queries) + PassportJS (Auth) + Redux (Client State) + LitElement/LitHTML (components/templates) + Router (open or Vaadin) + Vanilla JS, etc.
I'm sure I missed something, but you get the idea...
I don't really care for React, but would consider Vue. I know LitElement/LitHTML is cutting edge right now, but from building a few test projects with it, I really like the feel, how light and fast it is (no VDOM) and think it will go places. As long as I can build what I'm going to need with it, I think I'll use it.
I'm going to need all the basics: buttons, inputs, dropdowns, radios, cards for my forms. I will also need more advanced controls like a good Grid, Graphs/Reporting, and Date/Cal components - Menu Controls like side and header would be a plus. I've built these out before by hand, but really think it just makes sense to buy a toolset that will save me a ton of time and effort this time around.
This is where I think vaadin could come it. But for me to invest in a toolset and purchase the tools and support, I'd like to know their controls are 100% on board with Polymer3/LitElement and have a "cutting edge" path for thouse of us that live there. They need to fit in seemlessly into my existing LitElement templates and workflow. They need to be somewhat "light" and be removed from unnecessary dependencies and legacy baggage. They should be themeable, flexable and extensiable too.
You could even have a fully paid path with all the simple and advanced controls and if they're good, people like me will pay. Have advanced features for the paid, make only the very basic and very few free (just to get a feel for how good the controls are).
One of the big things they have going for them is I think they look fantastic (and I'm really picky about things like this). They also have a wide selection of components available. Just my 2 cents.
Having these 3 challenges solved, I assume updating the rest of components (e.g. button, checkbox, text-field etc) should be pretty much straightforward.
I think you're correct @web-padawan and I'm glad to hear you guys are working away on this!
Slightly unrelated, but I'll still drop a notice here since there have been some questions on the topic that referred to this ticket.
As of Grid 5.2.0, there is support for defining renderer callback functions in various contexts where you'd previously have needed to use a <template>
element. This greatly simplifies interop with non-Polymer libraries such as LitElement, React, Angular and Vue.js. Various other components releases made around the same time also adds their own renderer callbacks that can be used as an alternative to <template>
.
@mmohammad-pk here is the project containing all the free Vaadin components: https://github.com/web-padawan/polymer3-webpack-starter
You can see the demo at https://polymer3-webpack-starter.herokuapp.com
Hi @web-padawan , thanks for your example. I think your example already applied Lumo theme Light variant. Could you please share how can I switch it to Dark variant?
Thanks.
@thinhly197 you need to set theme="dark"
on some wrapper of the Grid, e.g.
<app-drawer-layout fullbleed theme="dark">
Note that Polymer 3 starter has some non-Vaadin components which are not affected by that. But for grid and any other Vaadin components it would work.
@web-padawan thank you a lot! You save my day
Hi @web-padawan,
I don't know who already to applied theme="dark"
, I would customize some things in vaadin-grid module as below polymer document.
https://polymer-library.polymer-project.org/3.0/api/elements/custom-style
But I think the importing for HTML page is not correct because there is no bower_components
in the polymer 3 project anymore.
\<link rel="import" href="bower_components/shadycss/apply-shim.html"> \<link rel="import" href="bower_components/polymer/lib/elements/custom-style.html">
I also try to fund custom-style.html after npm install
but it seems this file hasn't been added to polymer lib.
Could you please share some your ideas?
Thanks.
@thinhly197 for Polymer 3 you should import custom-style
element like this:
import '@polymer/polymer/lib/elements/custom-style.js';
explain polymer 3 lifecycle?
@web-padawan I can't find a Polymer 3 branch for vaadin-grid. I have a fork of the Polymer 2.x branch where I did some changes and need to apply those to the 3.x Polymer version as well. Did you switch to a private repo for the npm hosted code?
@HJK181 as mentioned in the README, we publish Polymer 3 version to npm, but it is generated from master branch using polymer-modulizer
.
OK, wow ... Nice to hear that for you the modulizer works without any manual step 👍 Thx for clearification.
Actually, we have CLI tool that runs modulizer for us. We also use it in Travis to test Polymer 3 version: https://github.com/vaadin/vaadin-grid/blob/8d3e77af3685a30ab107f08c65f5d3165cde3c76/.travis.yml#L63
Hi @web-padawan
thx for clarification, I ran the magi converter + Polymer modulizer and it looks good so far for vaadin-combo-box
. However I get the following error when using the combo box component in one of my elements:
DOMException: Failed to execute 'define' on 'CustomElementRegistry': the name "vaadin-combo-box-item" has already been used with this registry
at http://localhost:8765/node_modules/@vaadin/vaadin-combo-box/src/vaadin-combo-box-item.js:183:16
I'm getting the same error when using the official version from npm. Vaadin versions used in package.json:
"@vaadin/vaadin-combo-box": "^5.2.0",
"@vaadin/vaadin-grid": "^5.6.6",
"@vaadin/vaadin-select": "^2.2.0",
"@vaadin/vaadin-text-field": "^2.6.2",
Searching through issue it seams like I'm using incompatible component versions, but I can't find any matrix showing which of the elements can be used together.
Nvm. found out that an other component of mine used
import '@vaadin/vaadin-combo-box/vaadin-combo-box.js';
and the second one:
import '@vaadin/vaadin-combo-box/theme/lumo/vaadin-combo-box.js';
using the lumo import on both solved the problem.
Description
I would like to know if you have Polymer 3 port scheduled already and if so what is the time frame. I know that there is Polymer Modulizer which can help with this, but I'm hesitant to make the transition until you officially support Polymer 3.