Arthur, 

Thanks for this response.  It made me think harder about what I was doing and 
the way I was doing it. As a result,  I decided to concentrate on just 
upgrading lit-html and seeing how far I got.  It turned out quite straight 
forward,  and you might expect. There were a few import paths that caused 
confusion but some guessing was successful.  The change from using "$" to set 
attributes to that being the default,  and instead using "." explicitly to set 
properties,  caused some iterations in development,  but ultimately pretty easy 
to figure out.  I do kind of worry I've missed something....it was easier to 
grep for "$=" and "? =" than the way it is now,  but hey ho.  There was also 
some confusion over the third argument to the render() function,  which 
presented some odd typescript error... I ended up deleting the argument with no 
apparent consequence :/

So,  thanks again,  and I'll upgrade the custom lit-element to the released 
version next,  and then probably typescript after that. 

Regards, 

Max. 

On Tue, 1 Oct 2019, at 5:23 AM, Arthur Evans wrote:
> Hi Max,
> 
> It sounds like the code your contractor wrote was using lit-html 0.12 
> or earlier. In v0.13 
> <https://github.com/Polymer/lit-html/releases/tag/v0.13.0> 
> (corresponding to LitElement 0.6.3 
> <https://github.com/Polymer/lit-element/releases/tag/v0.6.3>) there was 
> a breaking change to the way directives are defined. 
> 
> Looking at what's being rendered, it looks like the app is defining a 
> directive that's supposed to render default content until a promise 
> resolves. In more recent versions of lit-html, you should be able to 
> import and use the built-in `until` directive for this:
> 
> https://lit-html.polymer-project.org/guide/template-reference#until
> 
> In markup, this would be used as `${until(promise, defaultContent)}`.
> 
> If the app has other custom directives, they may need to be updated or 
> replaced.
> 
> Arthur
> 
> 
> On Thu, Sep 12, 2019 at 6:01 PM Max Waterman <[email protected]> 
> wrote:
> > Yes, I see that - fair enough.
> > 
> >  However, doing that means the developer has lost the ability to 'just use' 
> > components...we now need to adjust our build tools to accommodate this 
> > issue - well, until import maps make it into the world, perhaps.
> >  Although, I guess it wasn't always that simple back with html 
> > imports&bower either - eg when using multiple components that use different 
> > polymer versions, for example. Onward and upward :)
> >  I went to a Beijing web group recently where someone presented some basic 
> > React, and it essentially looked very similar to lit-element, except with 
> > non-standard code. Since I did a short Polymer presentation to the 
> > Guadalahara PHP group when I went there some years ago, I thought I'd do 
> > that again here - except the big 'wow' was not having to have any build 
> > tools - I just did a 'bower install' for the google maps element, opened an 
> > editor (vim, no less), typed in html, started a server and web browser, and 
> > WOW...but that's not true any more, so it limits the 'simplicity' impact, 
> > imo.
> > 
> >  TBH, perhaps I just need to catch up...I've been using Polymer since 
> > something like 0.3, but have been stuck at v2 for some time. It's a 
> > daunting task to upgrade a whole app, not least the QA that needs to be 
> > done and there's always more important things.
> > 
> >  More relevant to the reason for this email thread - I have a another 
> > project that we had a contractor develop, and it uses an old version of 
> > lit-html/lit-element (the latter seemed to be hard-coded, not installed by 
> > npm - not sure if it has been modified, or not).
> >  My task is to add a qrcode scanner, so I found an element[1] and attempted 
> > to add it...but I'm having all sorts of trouble; I had expected to just add 
> > an 'import' line, and use the element in the html. It does sort of work, 
> > but the style of a completely unrelated element is being stomped on for 
> > some reason (with the opening tags of html comments, ie '<!--'...quite 
> > odd). I abandoned that effort and decided to try to upgrade lit-html and 
> > lit-element, so that I would only have one version of each in my app, but 
> > now my html is all 'gone', replaced with:
> > 
> >  "part => {
> >  part.setValue(defaultContent);
> >  part.setValue(promise);
> >  }"
> > 
> >  So, I'm not sure what's going on there. So, I'm abandoning that attempt 
> > too, and I'll try to move the whole project into a starter kit. I see 
> > Polymer still has one, though it's now 'PWA Starter Kit' - but there's also 
> > an open-wc (which I'd not heard of until you mentioned it). I wonder which 
> > one I should use.
> > 
> >  BTW, the project I'm trying to add the qrscanner to is in typescript, uses 
> > redux, and build with rollup. They all seem to be 'recommended' parts, but 
> > they're all somewhat new to me in this project, and while I've managed to 
> > pick them up somewhat from making other changes, I certainly don't grok 
> > them fully.
> > 
> >  Any recommendations for how to move forward would be appreciated.
> > 
> >  Max.
> >  [1] 
> > <https://www.webcomponents.org/element/@granite-elements/granite-qrcode-scanner>
> > 
> >  On Thu, 12 Sep 2019, at 11:58 PM, Justin Fagnani wrote:
> >  > Note that there's basically nothing about switching from HTML imports 
> >  > to JS modules involved here. Both only support URLs as imports 
> >  > natively. It's really the switch from Bower to npm, and from custom to 
> >  > standard tools, that necessitated the change to use package names.
> >  > 
> >  > On Thu, Sep 12, 2019, 1:46 AM Max Waterman <[email protected]> 
> > wrote:
> >  > > That helps a lot, thanks. The open-wc.org web site is especially 
> > interesting.
> >  > > 
> >  > > I'm glad that the value of build-less development is not lost on those 
> > working on 'the platform'. I find myself wondering if the dropping of html 
> > imports was done a bit too soon, but I guess it's really more like the 
> > alternatives are taking too long to arrive to replace them.
> >  > > 
> >  > > Anyway, thanks.
> >  > > 
> >  > > Regards,
> >  > > 
> >  > > Max.
> >  > > 
> >  > > On Thu, 12 Sep 2019, at 12:37 AM, Justin Fagnani wrote:
> >  > > > When we moved to npm we needed a way for modules to reference each 
> >  > > > other, and unlike with Bower where all packages are siblings of each 
> >  > > > other, there's no stable relative URL that we could use for this. 
> > The 
> >  > > > overwhelming community pattern on npm is to use package names for 
> >  > > > cross-package references and a tool (or Node) to resolve them. So we 
> >  > > > went with the community standard and used package names, knowing 
> > that 
> >  > > > there are a plethora of tools that can resolve ment, and that future 
> >  > > > browser standards like import maps will support package name 
> > resolution 
> >  > > > directly in the browser.
> >  > > > 
> >  > > > Until import-maps land, you can use a number of tools:
> >  > > > * `polymer serve` will automatically resolve bare specifiers on the 
> >  > > > fly.
> >  > > > * open-wc.org tooling will as well
> >  > > > * Bundlers like Rollup, Parcel, and Webpack will resolve names. 
> > Rollup 
> >  > > > with the rollup-node-resolve plugin.
> >  > > > 
> >  > > > Hope that helps!
> >  > > > 
> >  > > > On Tue, Sep 10, 2019 at 10:51 PM Max Waterman 
> >  > > > <[email protected]> wrote:
> >  > > > > Hi,
> >  > > > > 
> >  > > > > Is there a way to use a polymer element in a project without 
> > having a build step - neither one I run manually (eg polymer build), or 
> > automatically (eg polymer serve)?
> >  > > > > 
> >  > > > > I recently attempted this, but it seemed like I needed to have 
> > some import paths converted, and so I needed to use 'polymer serve'.
> >  > > > > 
> >  > > > > I don't recall needing any such step with the older versions of 
> > polymer - I just added an html import, and used the element. Perhaps I'm 
> > mis-remembering.
> >  > > > > 
> >  > > > > Is there a way to avoid any build step?
> >  > > > > 
> >  > > > > Regards,
> >  > > > > 
> >  > > > > Max.
> >  > > > 
> >  > > > > Follow Polymer on Google+: plus.google.com/107187849809354688692
> >  > > > > --- 
> >  > > > > You received this message because you are subscribed to the Google 
> > Groups "Polymer" group.
> >  > > > > To unsubscribe from this group and stop receiving emails from it, 
> > send an email to [email protected] 
> > <mailto:polymer-dev%[email protected]> 
> > <mailto:polymer-dev%[email protected] 
> > <mailto:polymer-dev%[email protected]>>.
> >  > > > > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/polymer-dev/d725e36a-04b7-4d0a-8974-571d8336bff1%40googlegroups.com
> >  
> > <https://groups.google.com/d/msgid/polymer-dev/d725e36a-04b7-4d0a-8974-571d8336bff1%40googlegroups.com?utm_medium=email&utm_source=footer>.
> > 
> >  Follow Polymer on Google+: plus.google.com/107187849809354688692
> >  --- 
> >  You received this message because you are subscribed to the Google Groups 
> > "Polymer" group.
> >  To unsubscribe from this group and stop receiving emails from it, send an 
> > email to [email protected] 
> > <mailto:polymer-dev%[email protected]>.
> >  To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/polymer-dev/c8cc27c7-76fa-4830-8b67-c813b82bfe2f%40www.fastmail.com.

Follow Polymer on Google+: plus.google.com/107187849809354688692
--- 
You received this message because you are subscribed to the Google Groups 
"Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/polymer-dev/217f1ad8-01ea-4e82-bbeb-afdd90fcbf13%40www.fastmail.com.

Reply via email to