 Hey there, folks. Rob here. Welcome back to the show. So it's been a while since we did one of these, but I thought today would be a good time to do another episode of Ask Polymer. So I went on Twitter. I asked folks if they had any questions for me. And here are some of the top questions that were sent in by you, the actual viewers. So the first question is from Micho, who asked, how do I make the app drawer panel automatically close when I click a link in my application? So that's a really good question. I think we actually maybe used to do this for you using the old Polymer Starter Kit. We're not doing it now in the new Polymer Starter Kit. But basically what you can do is you can actually wire up a binding to the opened property or the opened attribute of the drawer panel. And then you can just toggle that value every time the router changes the page. So that might not make sense when I'm just saying it like this. And what I'll do instead is I'll drop a link down in the description that has an example. So you can just follow that. And also, I think we might just add this behavior to the Polymer Starter Kit, the one that we just rolled out. Maybe expect a point release soon when we just add this in so you don't have to wire it up yourself. So thank you for that question, Micho. All right, this question comes from Eric Bidleman, who asks, I hear Polymer 2 is out. What's up with that? So yeah, maybe some of you have seen on Twitter and on the Polymer blog. We were recently tweeting that we have a preview branch of Polymer 2.0 available right now. We can find that over on the GitHub's. And I will include a link to that as well down in the show notes. So Polymer 2, the main idea there is we want to get folks onto the new V1 versions of the web component standards. So custom elements V1 and Shadow DOM V1. The current version of Polymer 1.x is based on the old V0 implementations. Those shipped in Chrome and Opera and some other browsers experimented with those versions of the standards. But they are never going to be sort of the native one that ships everywhere. Instead, after sort of reworking things a bit, the browsers decided to make some changes. And those changes are in the V1 specs. So that's what's going to be shipping in all the different browsers. I believe Safari recently just shipped Shadow DOM V1. It'll be coming in Chrome really soon. And because there are some breaking changes, we needed to migrate Polymer as well. And the important thing to note here is that those breaking changes for the web component specs, those are probably set in stone now. So we don't have to worry about suddenly a V2 appearing out of nowhere for the web component specs or anything like that. The nice thing is that going forward, web component should be backwards compatible. So yes, there are some breaking changes right now, but hopefully minimal pain. I wrote down a few things from Polymer 2 that I'm really excited about that I wanted to tell you all about, stuff that I just think is super cool. Aside from moving over to the new standards, we're going to be providing kind of like a backwards compatibility layer. So if you've got a bunch of Polymer 1 elements and you want to try and start to migrate those to Polymer 2, we have the old Polymer constructor available to you. So you can seriously just do like a few small changes and voila, you've got Polymer 2 elements. But the other thing that we're doing now is we're baking in support for ES6 classes. So that's something that a lot of people really wanted. Now the default and the standard encouraged way to build a Polymer 2 element is going to be to actually inherit from a class. And then you've got all sort of the niceties of working with ES6 there. We're getting rid of things like Polymer.dom, which was always really confusing for folks, the whole shady DOM thing. Instead, we're going to be shipping a new improved shadow DOM polyfill. We're going to stop talking about local DOM and all these shady DOM, these random terms that never made sense. Instead, we're just going to say, hey, it's shadow DOM. We've got a new polyfill. It's nice and fast. And we're making the data binding system a lot easier to reason about too. So if you ever had issues where you would change like an object inside of an array or change like an object sub property and things just like wouldn't update, we should be fixing those in Polymer 2 to make that just like a lot more straightforward. So that is kind of a high level overview. Again, I'll include a link for the 2.0 preview branch down in the show notes. So you can go check it out yourself, read through the read me and give it a test run. I'm really interested to hear what all of you think. So please leave some comments down below with your thoughts on that. So thank you, Eric, for that question. All right, next question. Sam Sakoni asks, I hear you are a corgi. What is up with that? So yeah, that's true. My spirit animal actually is the corgi. Thank you for that question, Sam. All right, our next question comes from Jerry, who asks, how do I implement ES6 syntax with Polymer CLI? So today, what you can do is you can use the custom build generator that we showed off, I think maybe two episodes ago, I'll include a link down in the show notes to that particular episode. And what that does is it actually kind of gives you a little escape hatch out of the Polymer CLI build. It lets you actually use the same node module that powers the Polymer build, but it lets you also kind of hook into its lifecycle and add your own gulp tasks. One of those gulp tasks could be something like Babel. So you could write all your elements using HTML imports. The Polymer build will actually split out the JavaScript into its own stream. You then pass that through Babel and then it recombines it all at the end for you. So that's the option that you could use today. However, as I mentioned before, we're gonna be rolling out full blown ES6 support in Polymer 2. So if you're able to wait to Polymer 2 time, we might have a better story for you there. It might be a little bit easier to use. So if I was doing this today, I would actually probably stick with just like, the current Polymer 1 syntax and then kind of wholesale move over to ES6 when Polymer 2 rolls out. Hope that answers your question. Thank you, Jerry. All right, the next question is from Steven who says, I'm still confused about how to load in third party JavaScript in my elements. So that's a good question. You know, what a lot of people do, I've seen kind of two approaches. One approach would be, you just say, hey, I depend on this library and you've got to include the script tag for that library before you import your elements. What I actually prefer to do is to take the script tag for whatever dependency I'm depending on, put that into its own HTML import and then have my elements import that file. The nice thing there is your elements are now explicit about their dependency because, you know, that link tag is up at the top of their definition file. And also HTML imports will de-duplicate multiple requests to the same resource. So if you've got, you know, five elements that are all trying to import the same thing, it's actually gonna only be loaded one time. So that's the approach that I really recommend using. That's the one that we've used in some of our elements, like the marked element. So yeah, hopefully that approach works for you. And also I think in the future, we're probably gonna also be exploring things like, you know, maybe how we can use like ES module loaders or something like that. It's definitely in the Polymer 2 realm of possibilities. So we might have an improved story there as well soon. So yeah, thank you Stephen for that question. All right, next question comes from Thomas who asked, once all web component features are broadly and correctly supported in all major browsers, is Polymer's job done? So yes and no a little bit. Definitely the job of polyfilling web components is done at that point, which is great. We want to get rid of polyfills. We want to get rid of any sort of inconsistencies that they introduce and just be doing everything native. But web component standards are inherently low level and that's by design, right? They're supposed to give developers maximum flexibility. However, that also means that it can require a fair bit of code to create your own elements, stamp out your shadow DOM, put your templates inside of them and stuff like that. So Polymer will probably always be around in some fashion to offer this sort of like helper support, right? Sometimes we refer to it as like sugaring the native web component standards, just making you essentially much more efficient. So that has kind of always been the direction for the library. We wanted those polyfills to sort of evaporate away and then you're just left with this really nice, clean helper library that just makes you, you know, more efficient as you're building components. So thank you, Thomas, for that question. All right, our next question comes from a user on Twitter named GBX who says, how should web components be written to let applications override their default locales? So I am not personally an expert on localization or internationalization, I can't even say it. L10N, I18N, there we go, that's the easier way to go about it. My teammate Monica Dinkalescu has actually written some behaviors to help with these. So the one that you would be interested in is called the app localized behavior. And basically you define a JSON file full of different localized strings based on the locale or their keyed off of the locale. And then based on the user's locale, it then in your element, it uses a little computed binding to match up whatever text you're using to that JSON file and use the right localized version. So our internationalization library works in a very similar fashion. The one thing to note is that these depend on the internationalization API. And so if you're in a browser that does not support that API, you're also gonna need to include a little polyfill. But that is linked to from the repo for app localized and the I18N behaviors. I'll include a link to these down in the show notes so you don't have to listen to me try and say these words anymore. But yeah, give those a shot and see if that helps in your app. So thank you for that question, GBX. All right, next question is from Vladislav who says, what's up with 2.0, Polymer 2.0, I'm assuming, and TypeScript. So there's no plans right now to migrate over to TypeScript or anything like that. However, we do have a lot of members of the Polymer team who really, really like TypeScript and we definitely wanna make sure that we are supporting it better. So I think if you're trying to do this today, you can maybe use something like the generator custom build that I mentioned before, which we're gonna link to down in the show notes to add the TypeScript compile step to your build process or something like that. For 2.0, I'm not quite sure what the exact game plan is gonna be, except for I'm almost certain that we're gonna have some better TypeScript story, some sort of improved story around that because we have so many team members who like it, we have so many Googlers who like using TypeScript, I definitely wanna explore it more myself. So I definitely think we'll probably have some more to talk about there. It's little early days right now for Polymer 2.0 to know exactly what that strategy is gonna be. But if you are interested in TypeScript and you're interested in Polymer, stay tuned because I'm sure we're gonna have something more exciting for you in the future on that topic. So thank you, Vlada's Law for sending that in. All right, the last question comes from Aido who says, how do I share information when I am transitioning between two pages and what are the best practices for communicating between elements? So I'm actually gonna answer this sort of in reverse order because I think the second answer helps answer the first question. When you're communicating between elements, you actually probably don't want to have like siblings talking to each other or anything like that. We generally try to discourage that, mainly because it means that element A has to be sort of coupled and sort of know about element B over here. And we kind of don't want that level of coupling. Instead, what we recommend is to figure out a common parent between both of your elements and have your elements be kind of like as simple and as dumb as they can be and just sort of dispatch events out to that common parent, like, hey, something I was clicked on or something like that. And then the common parent can act as sort of the orchestrator saying, oh, I hear that this child over here was clicked on and I know that that means that some action needs to happen with child B over here. What this does is it keeps element A and element B very simple and reusable and all your business logic then kind of gets moved up into that like higher order element. And we usually refer to this as like a mediator component and I'll include a link down in the bottom to my teammate Kevin Schoff's talk from I think this was from like Polymer Summit maybe two years ago or a year ago where he talked about this pattern and how we tend to use it in most of our apps. So that's how we recommend doing communication around the page. And so then the first question was how do I share information when I'm going from page one to page two? Well, in that case, I think, you know, if you have information that needs to belong to multiple pages, that to me is stuff that belongs in one of those higher order components like something that, you know, kind of lords over all of the pages even and it's just binding it down into the child pages. And, you know, you can have that higher level component listen for changes coming out of some of these lower level components and changing its state and then pushing that down. But that way, again, you're sort of, you're simplifying things so that the business logic that, you know, we've got two related things, the business logic for that is gonna live higher up and they don't have to try and talk to each other and figure out how each other works. So yeah, I hope that answers the question. I know it's sort of like a broad abstract answer, but that's generally the pattern that we recommend and definitely go check out Kevin's talk, which covers it in a lot more detail. So thank you, Ido, for that great question. That about covers it for today. If you yourself have some questions for me, you can leave them down below in the comments or you can ping me on a social network of your choosing at hashtag Ask Palmer. As always, thank you so much for watching and I'll see you next time. All right, you ready? Localization, internationalization. I just slam it all together so like internationalization. It's close enough. That's why you just shortened it, right? I-18N.