Closed logicalphase closed 5 years ago
Dabolus
commented
6 years ago Completely missed that blog post, thank you for letting me notice it! Yeah, that's exactly what happened to me, but I decided to avoid investigating more because I was working on a blocking bug (the polyfills not working). By the way, thanks for your time, any help is always appreciated! I'm assigning it to you right now
Dabolus
commented
6 years ago About that blog post, I read it and found two possible enhancements for this project:
logicalphase
commented
6 years ago Happy to help if I can. Thanks for the fills fix. 👍
On Thu, May 3, 2018, 11:41 AM Giorgio Garasto notifications@github.com wrote:
Assigned #72 https://github.com/Dabolus/polymer3-webpack-starter-kit/issues/72 to @hyperpress https://github.com/hyperpress.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/Dabolus/polymer3-webpack-starter-kit/issues/72#event-1608146782, or mute the thread https://github.com/notifications/unsubscribe-auth/AYC27bqh4rEp4IaDEAu8apKGR4eaiihpks5tuzMogaJpZM4TxZIi .
logicalphase
commented
6 years ago I'm in total agreement. lit-html looks really good, and I'm liking the MDC fix for presentation.
On Thu, May 3, 2018, 11:46 AM Giorgio Garasto notifications@github.com wrote:
About that blog post, I read it and found two possible enhancements for this project:
- Migrate to those new material components that are already available here https://github.com/material-components/material-components-web-components
- Migrate to lit-html, as it seems to be the next standard for HTML template literals. It shouldn't be too hard to do that using LitElement https://github.com/polymerlabs/lit-element (that is also the element the new material components depend on)
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/Dabolus/polymer3-webpack-starter-kit/issues/72#issuecomment-386360428, or mute the thread https://github.com/notifications/unsubscribe-auth/AYC27U3olDUnIyTQJCX0Br5g9Bnn74i0ks5tuzRbgaJpZM4TxZIi .
logicalphase
commented
6 years ago I've been reading up on lit-html, I've opened a local git rep and branched for this change. But, I was thinking it might be good to open a branch on your GitHub project for LitElement, MDC, and I can work in fixes for breaking changes to P3 final prerelease and then 3.0 rollout expected at I/O 2018.
It's clear lit-html is going to be the default, and I can see why. So, I think it will keep this TypeScript PSK synced more closely with structure of official PSK in non-TypeScript. Pretty exciting really.
Anyway, I've got time mid next week to devote uninterrupted days to this. But I'm certain I'll need to run proposed PRs. Looking forward to seeing this project stand out as the TypeScript option for PSK P3.
Dabolus
commented
6 years ago I created the refactor/lit-html branch for you, now I'm editing some repo permissions so that you can do whatever you want on that branch. By the way, yesterday I played around a bit with LitElement, and I noticed that it doesn't work well with this "separation of concerns" layout because it uses variables inside the JS template you pass to it to update only what is necessary, but the external HTML and SCSS files we are using are injected in the template as two big variables, so lit-html will update the entire element UI when a variable is modified. I didn't find a workaround to this for now, but probably a custom loader will do the work.
logicalphase
commented
6 years ago Thank you for doing that. Yes, it looks like lit won't play well with this. I've fired off an email to Justin (author of lit-html) to see if he has any best solutions for this. Either way will let you know as soon as possible. Thank again.
logicalphase
commented
6 years ago Just chatted with Justin on Slack. He said he plans on working in a html compiler after Google I/O. But he pretty strongly recommended modifying the structure back to single file Element layout. He can think of several problems beyond injection and feels the performance disadvantage with LitElement would be significant even if we can find a workaround. Not sure how you feel about it, but combining the Element concerns is not a huge bother to me.
Dabolus
commented
6 years ago I tried to think at various possible solutions to keep the template separated from the rest:
import {html} from '@polymer/lit-element';export default (props) => html`
`; ``` That is actually based on the technique the guys working on [MWC](https://github.com/material-components/material-components-web-components) are using The first technique can (and will) give **a lot** of problems, firstly because it requires a lot of work, and secondly because most probably it won't work for every situation. The second technique seems pretty interesting. The only limitation it has is that from the separate module you won't be able to access to the element's instance fields, as we are out of the element class, but this would actually make sense, since logically the template should only work with the variables inside the properties object. By the way, this limitation can actually be overcome by passing `this` to the separate module. I'm not completely sure that this would be the best solution, though. What do you think? Of course I have nothing against the template-in-class approach, I'm just trying to see if there are any other possibilities.logicalphase
commented
6 years ago I've been playing around with similar ideas without much luck. Weighing the benefits of lit-html, especially moving forward, against the amount of work it would take (and that's assuming there would be use cases we can't think of right now), I think the best solution is to adopt lit-html and refactor the layout to template in-class.
Let Justin work on an html compiler add-on. That potentially solves this issue without additional code and maintenance on this end, and it just seems like the best option right now to me. We can always revisit this if he and the lit-html project leads sort it out.
And from my conversations with Polymer leads, including Justin, LitElement is going to be the agreed upon method. I like separation of concerns. It's more familiar to me, but it's certainly not a deal breaker. I doubt other users will care, and it might make it easier to be able to refer to docs and projects using lit-html for users who want the benefit of typed language and the universal adoption of Webpack. That's my 2 cents ;-)
Dabolus
commented
6 years ago Yeah, makes sense to me. Since you're working on this, make sure to also update (or completely remove) the part of the readme that talks about the separation of concerns to make it coherent with the new project structure
logicalphase
commented
6 years ago It's in my notes list. Thanks again for setting the branch up for this. Plan to have commits up by Wednesday CDT.
Dabolus
commented
6 years ago Just noticed that the new prerelease 17 that came out yesterday broke everything again because it is using import.meta, that isn't even transformable by babel yet. It's probably better to lock the dependencies resolution to an older prerelease until Babel or Polymer fix the issue
logicalphase
commented
6 years ago Yes, I'm looking at this as well. Better if we let them get past I/O and get the release of 3.0 done before putting too much time in breaking prerelease changes. I'm going to work in lit-html and MDC, but not much else 🙂
logicalphase
commented
6 years ago So, I'm pouring through Polymer 3 changes, but mostly getting up to speed on LitElement and Redux for state management. There's a lot more to this than I originally thought, but the performance gains are real.
So, I plan on taking a few days to wrap my head around LitElement and how best to adapt into it from here. Let me know if you have any questions. Cheers.
logicalphase
commented
6 years ago I've made some progress on moving on into LitElement, but admit this is moving slower than I'd hoped. Love the new tooling, mostly. But documentation is really sparse, and MWC seems more of a promise right now and less of a ready to use feature than I first thought. Just wanted to provide a bit of an update. Polymer team definitely needs to get their documentation situation fixed. Telling users to use LitElement, but providing docs for implementing polymer is confusing. Hope you are well.
Dabolus
commented
6 years ago Hi, sorry for the quite long absence, I've been playing around a lot with LitElement too. After these days, I can say that upgrading this project to LitElement would basically mean to rewrite it from scratch. Since Polymer 3 still exists, but it is not recommended to use it, the best thing we could do would probably be to:
I will start working on the second point this weekend, it would be great if you could work on point 1 as soon as the Polymer elements get updated to the final Polymer 3 release. At that point, we can add the warning on the README and completely focus on the new project
logicalphase
commented
6 years ago I too have been really swamped with work this past week or so, plus my daughter (who is living in Belgium) got really sick and was hospitalized on a day trip to Germany last week. That has my wife and I scrambling to support her there. So, between travel, family emergency, and work, I've not had time to do much else. Daughter is out of the hospital and back in Belgium recuperating now, and I am back as well.
I agree with your plan. It's just too much to workaround everything that has to be done to keep the best of this project converted to LitElement. Honestly, LitElement seems a bit rushed to production to me. The docs are scarce and examples scattered between projects. MWC from Material Design is at best, in Alpha right now. Much of it doesn't work, docs are confusing, and naming conventions between the old and new components are awful. I've made that known and hopefully a lot of this will be fixed soon. I will have time this weekend to get the project updated to Polymer 3 with the latest pre-releases of remaining elements. Will follow up then ;-)
I caught your note about breaking changes on the latest polymer element update. It appears, from my scan of a post from Polymer earlier today, that they are moving away from many of the paper styles and components in favor of using what will be called Polymer Material Components. This looks like the right change to me because since Polymer started incorporating layout into the app elements it's caused issues with Paper Elements. It's also pretty well known that Polymer hasn't been able to keep up with Google Material Design regards to standards, elements, and animation. So, this should be a good thing.
But on running an update to latest PSK and polymer pre.13 with elements pre.15 my app broke. Turned out to be paper styles like buttons, etc. I think this is probably what happened to you earlier. I removed paper styles and and some components and, while it hurt some styles in the app, everything does work. So, if you want to assign this to me, I'd be happy to work on it and create a PR when ready. Shouldn't take long (I hope) ;-)