Welcome to the Argos Toy Unboxing. Today we're looking at the cute and adorable characters from the popular CBBs show Hey Duggy, and we have lots to play with. Let's see who's joining us today. It's the cuddly Squirrel Club members Tag, Rowley, Happy and Betty. Tag is a kind and sweet rhino and is fairly clumsy. He's always bumping into something. Rowley is a hippo who's enthusiastic about everything. He's always interrupting and isn't good at listening, but he's very good at being very loud indeed. Betty the Jolly Purple Octopus She's a little bossy and would love to be in charge. She's also very clever and loves to read. Plus she's competitive and always wants to be first, and if she isn't, well, you could say she's a bit of a sore loser. Exclusive to Argos is Happy the Crocodile. Happy loves water and if there's a puddle to splash in, Happy is so, so happy. Like all our soft toys today, each fun, colourful character is suitable for children of 10 months and over. These guys here are all approximately 20 centimetres tall and say their signature phrases from the show, and they all come with a child's safe feature badge for you to wear. Next we have the Woof Woof Duggy Soft Toy. Duggy is the Squirrel Club Leader. He's very kind-hearted. He makes sure all the children are having fun, learning and playing games. He loves to take them all on adventures. If you pat his head, he woofs or press one of his four embroidered badges and he makes sounds, says phrases from the show or plays the theme tune. He comes with two child's safe badges for you to wear and stands at approximately 30 centimetres tall. He's super soft and cuddly with wonderfully floppy ears. Now who else is here? Another Duggy! This Hey Duggy Soft Toy is around 20 centimetres tall and is cute and cuddly like the real Duggy, perfect for your little one to take around on all their adventures. And of course our lovable friend here makes the perfect Snuggle Companion. We hope you've loved this Argos unboxing with Tag Rowley, Betty, Happy, Woof Woof Duggy and the Hey Duggy Soft Toy all from the show Hey Duggy. They're all perfect for hours of fun and the characters are oh so cute. Let us know which one you like the most.


Good morning, guys. So I'm going to be talking about web components and how we could go about using them to build applications. So before we get started, a quick show of hands. How many of you guys have started playing with web components? OK, nice. And how many of you have read about web components, watched those huge amount of videos that are available out there, and things like that? Probably the same amount, OK. So good. A couple of guys have started working with their components. But I think in a couple of months from now to about a year, a lot more of you are going to be working with the components. And there are two primary reasons for that. One, it's going to become the de facto way of building web applications. And two, and a more compelling way is your clients or your product managers have heard about this, have heard about the cool stuff that it can do. And they want to use that in the next project. So they are going to be forcing you to start working with web components. Sorry, yeah. So I kind of tell this to a lot of folks that the approach that we use to build front end is broken. And when I say broken, that's more in the little sense of breaking things apart and putting them back. If you look at the way we build our applications right now, right from the design stage to the final deployment, you create the designs in Photoshop page by page. The Photoshop designs are finalized. It goes to the HTML person. The HTML person takes those Photoshop's, slices them, dices them, extracts the assets from there, and then goes about creating the HTML, CSS, and the JavaScript. And when that goes to the backend person, he or she again breaks that apart, takes chunk of HTML from there, puts them into their include files or into their components or anything, and then builds that out. So every step involves breaking things apart and putting them back. And the problem with that is, by the time your application is ready for launch, it's not really matching the original Photoshop comps that original build, right? And that leads to a lot of frustration. A small graph that I had with regard to the levels of frustration across the various stages of the whole project that we work with. So as the teams are working on the front end and the backend, frustration levels are usually lower, right? Once you start integrating your front end and the back end, frustration levels start to rise a little bit between the teams. You're adding the HTML, so the CSS is not working. The JavaScript sometimes is not working and things like that. That settles down. And then towards the end of the project, a few weeks before going live, you have this whole thing called fixing UI issues, right? And that's when I think the frustration levels probably shoot up the most, because anything and everything can be plugged in as a UI issue. And that's when you're testing it across your IE, you're testing it across your mobile devices and things are breaking all over the place. The front end guy is blaming the backend guy. The backend guy is blaming the front end guy, and it's a complete, yeah, you know what it is, right? Many times the reason for that is essentially because we look at building applications as pages. But essentially, they're more about building them as components. A quick example that I have over here is Amazon. So Amazon's homepage, product listing page, and the product details page, right? Essentially three different pages. But if I look at them, I could also say that they are essentially a collection of components. The top header is one single component. I've got a carousel component out there. I've got a product listing grid, which essentially gets repeated across my three different screens and so on. So if you start building applications or you change your workflow to building applications from a components-based approach, I think things, your audio frustration levels, would significantly reduce. And in fact, at Razerfish, we have moved to a state where even your Photoshop files are built-in components. So each of these become smart objects that are kept at a single location. All the designers pull it from there. And then they compose their designs, all their pages from those initial components that we have. So I think a components-based approach is a really good thing. And to be honest, it's not a new thing. It's been there for ages. Every single framework that's been out there has been trying to create components. So we've got the jQuery plugins. We've got the dojo toolkits. JSP has got those custom tags and things like that. The problem with most of those is interoperability. Each of these tools or frameworks has a different way of creating these components. And they cannot be easily mixed and matched. I mean, you can't dream of taking an AngularJS directive and putting it into a jQuery. Or even if you take two jQuery plugins and put them on a single page, there are going to be a bit of conflicts and stuff like that. So that's one of the main hurdles when it comes to working with components. And that's essentially the biggest problem that web component solves. Because it's standard-based and because it's all encapsulated and things like that, you can very easily build components on the web component standards and move it across wherever you want. A small example of what really component is and how it can work. So a simple component, this is called decalendar. It's available in components.io. Really nice, nice Google's material design. I could change it, I can move it back and forth and things like that. But just by looking at this, you can visualize there's a fair bit of JavaScript involved, there's a bit of CSS involved and there's a lot of DOM involved. Now to build this, we essentially assume that I copy all of this HTML, CSS, put them into my respective places, initialize whatever I need to initialize and things like that. But because it's a web component, all I need to do this is only this much lines of code. So what I do initially is call my component file and then call the custom element tag over here. That's it. And with this, the whole component and the widget works. The first thing for this particular case, you might probably need to do a Bower install because it would further install further dependencies and things like that. Let's take a more simpler example, right? So I needed to create the tag name, the meta refresh tag name. It involves two simple processes. One is I create a component file. I call it name tag.html. I will import any dependencies that I have on top of it. I would write my DOM over there and any CSS styling or script that's required over there. That's all encapsulated within my components file. And on the main file, all I need to do is simply call it, import the component file and call the name tag. That's all that is required for me to make this component work. So web components, it's essentially a collection of four different technologies or four different WCC specs that are available. Custom elements, HTML imports, templates and shadow DOM. If you go and read about, if you go to any video tutorial or any article that's on web components, they're gonna be talking about this over and over and again. So these are the four technologies that essentially comprise web components. It's not a mask that you need to be using all four of them together. You could just pick up and say, hey, I'm gonna build a web component using only custom elements and templates. That's fine, it'll still work for you. Or I could just use HTML imports and custom elements. It still works. So you can go about creating web components and you could create them in plain vanilla JavaScript and CSS. But you also have libraries. So there are three popular libraries that are available out there. Polymer from Google is the most popular and I would say the most feature rich. It has a lot of stuff available. A couple of things about Polymer is it uses all the four technologies. It's fairly opinionated. They have a very opinion, I mean, they're a very clear way of how things should work and they're trying to drive that down. It's fairly declarative. I could create components without writing a single line of JavaScript so that's really cool. And to all of this, it also adds a thin layer of features on top of it. Things like two-way data binding, things like automatic support for touch, registering of components, all of that comes in automatically with Polymer. The X tag on the other hand is from Mozilla. And their focus is that we will build a library that allows you to create custom elements. We do not worry about the other specs. Well, you can still go ahead and use them but our main focus is that we allow you to create custom elements. The good thing with that is it's got support from IE9 Plus. The third one is Bersonic. Their approach to this whole architecture is that, you know, obviously things are not going very, the specs are still in development, things are in the flux, things are changing. So what we try and do is when you're building web components, we are more like a transpiler. We will convert that into JavaScript and CSS and make sure that that works equally fine across all your browsers. So those are a couple of libraries. Let's go back to our whole example again and see where are those four technologies and where do they really fit in? And a couple of characteristics about each of them. So that's your HTML import, right? That's the HTML import through which I load my component file. The good thing to know about that is HTML imports are usually dedupt, which means if I'm loading multiple components and all of them are accessing the same component file, it loads only once. Similarly, the JavaScript that's called is called only once. So that's a good thing about that. Custom element, that's your custom element there. When you're creating custom elements, the thing you need to keep in mind is you always need to have a hyphen in it. That's how you differentiate your custom element from the native elements that's available in the browser and also any future HTML file elements that come up. That's your template tag. So you could put DOM, CSS, JavaScript all into the template tag and you could load that in. And finally, that's your shadow DOM. So you could register that DOM as a shadow DOM and shadow DOM brings all sorts of interesting characteristics to the web component. So try and understand what shadow DOM is all about. This is how it essentially looks. So if you look at my DOM tree, you got a body tag, you got the header tag and inside the header, I would have a nav, I would have some divs, they got a section tag and then I've got my element. That's a custom element. So things that are part of the HTML, the regular tags, they all are all available on what you call as a light DOM. And things that part of the custom element that would go into something called the shadow DOM. And like I said, shadow DOM is the one that gives in some interesting characteristics. One, it allows you to do style and encapsulation by default, that comes in by default, which means whatever styles that I write in my custom element will not bleed onto my main page. And at the same time, any style that I write on my main page would never come into my custom element. Room of the day is when you're learning JavaScript, sorry, you're playing with the J queries and you add two or three components on your screen and suddenly all your H2 tags have become red or something like that, right? You'd never have that kind of a situation when you're doing web components. So while the styles are encapsulated by default, you can override them. You can use pseudo elements called shadow, or you could also use the slash deep combinator to go and completely ignore all the shadow boundaries and just style all of what that's required. Unfortunately, the JavaScript side, it's not really localized. I mean, I could still write JavaScript with my custom element that's available on my document route. But events are usually retargeted back to my shadow host. So let's go back to that example and just play with some custom elements. So the name tag example that we had, and probably while we do this, so that's your method refresh name tag out there. Now, the code for that is here, very clear, but that's my name.html, that's the main HTML file, that's my import statement, and this is my component file. I'm probably gonna move it back here so that it's easier and more visible, right? Bit of JavaScript, there's no JavaScript, actually. There's a CSS and very simple DOM. Now, if I need to go ahead and say create multiple copies of this tag on my page, like you've got multiple speakers, right? And I want to have the name tags probably one below the other. All I would need to do is go into my name tag file, find out my custom element which is here called name tag, I'm just gonna duplicate that and say, so just duplicate the name tags and refresh my screen and hopefully they all come in below the other. So now, essentially the whole thing which has got an image, it's got a couple of divs, all of that is just simplified to one single element. And I can just go about repurposing this as much as I want. The other good thing about custom elements is I can create attributes. I can create custom attributes on top of this. So if you notice that I have this thing called speaker and the speaker is the same for all, obviously I want to change that. I want to have them as say volunteers or participants. So what I could do here is I go into my name tag file, I'm going to define attributes. I'm going to call this called type for now. And this is using polyverse, it makes life a lot easier for me. And wherever I need to display this as a name, I'm going to change this, just remove the words. And I probably also want to do some color coding. So let's see if that works. So essentially I have a thing called type. I call it using a curly bracket, double curly brackets into my component. And I have a couple of styles also defined over here. Boss, volunteer and participation with a very simple background color. Can go back to my name tag, add my attributes now. So let's refresh. So now the boss has got a pink color, Rita has got a brown color, the volunteer name has changed, and participants have that. So now you're able to create components and you're able to give it to your team members and say, hey, this is a component, these are the attributes, use this to go ahead and style it. And so all of this works. Now what if you have a new person on board and he doesn't understand and he goes and does something like, just goes and puts in a div and he says a really thick border radius red for the div.  But the div actually works. So if I had a div tag on screen, so the div really works, but the red color doesn't go anywhere into my component. But if I wanted to override this and I want to make sure that all the elements on my page have this particular red border, then all I would need to do is just say, use this combinator, and that should make everything red. So that's how you could kind of override the styles and go for the deep end. So that's how to go about how you could go about playing with custom elements. I'm sure this is a question everybody is very eager to know. How about browser support, right? And the truth is it's not very great. By default, this is how it looks. So you have Chrome and Opera supporting all the four specs. So that's Chrome on the desktop and also on the Android. They support all the four specs. The template tag has a fair amount of acceptability and you've got Safari and Firefox and other supporting it. HTML imports, custom elements and shadow DOM, not so much. What do we do? Well, we have to rely on polyfills. As of it, there's no two ways about it. The most common and the most popular polyfill available is called webcomponents.js, which allows you to polyfill all those four elements and you can get them to work across all the screens. And with polyfills, this is how it would look like. So with polyfills, now thankfully, you have support right from IE 10 onwards and you can support every other feature over there. Well, it's not that just because I add a polyfill, hey, my life just becomes all easy and great, everything just works. Unfortunately, polyfills is not a magic wand. There are a couple of woes to polyfills. First one, the file size. It's about 100 KB minified. That's the main. Second is not all those technology, all the four technologies are equally well supported with polyfills. So things like HTML imports, templates or custom elements are fairly easy to polyfill. Shadow DOM is the biggest problem. In fact, about 85% of the code that's written in your polyfill is only meant for Shadow DOM. And that's also one of the reasons why Google has launched another version of the polyfill called webcomponents-light.js, which polyfills everything else except Shadow DOM. And that's about 28 KB minified. The other thing with polyfills is, and because we work with mobile devices where every single request or every page, or the page weights are a lot of importance, you could conditionally load polyfills. So this is a code from Xgif. I mean, Xgif has made this very popular, this conditional loading of polyfills. So you could go in and check whether your browser is supporting any of these features, and if it does, then don't load the polyfill. But if it does not, then just go ahead and load it. So that's what polyfills. Now, what happens with webcomponents is, I think the moment you get comfortable with the component, the moment you start playing with them, the teams just go berserk.  And that's essentially, I think, I'm sure that would happen once you start working on it. And a way to kind of streamline that and stay in this whole sane mode is try and look at the atomic design pattern. So Brad Foster's this atomic design system, and what he says is that when you're building applications, treat it as atoms, molecules, organisms, templates, and pages. So atoms are your most basic building blocks. They would be a single element, style, and things like that. A molecule is a group of atoms together, and organisms are so on and so forth. So if you start following this atomic design pattern to building webcomponents, I think that builds a lot of rational across this entire thing. Otherwise, things can go out of hand. I'll try to quickly put together a couple of components and try and categorize them as atoms, molecules, and components. These are from the polymer library. Polymer has a whole bunch of core components and paper components that it has. So things like your core icon, or your paper slider, they would be called atoms. Even things like core Ajax. So one thing to remember about web components is they are not necessarily UI elements all the time. They could even be a piece of functionality. Like for example, the core Ajax doesn't have any UI representation. It simply makes an XHR request to the web server and gets data from there. So all of them become atoms. I could take these atoms, put them together, and convert them to molecules. And a core toolbar is an example of that. A core toolbar, if you notice, is an example. It's a combination of the core icon, a regular div, and a couple of other icons. Similarly, a core header panel is a combination of the core toolbar and additional div. So that would be molecule. Going a step further, you have things like the core draw panel. How many of you have looked at Google Polymers core components by any chance? Right, okay. Sure, so you probably guys know they understand this a little better. For others, a core draw panel is a responsive layout wherein I can have a header component, I can have a content area, and as I stretch the header component, either falls into a hamburger menu, or it falls into a right-hand side or a left-hand side panel. So that's our core draw panel. And I could use that to create a design like this. And the last is probably templates. And most probably, these are gonna be custom components that you have created which are essentially entire pages. So in one of the apps that I was working with, we kind of used product listing as a single component. So that's got a two-header toolbar, it's got a core draw panel, and a couple of things built into that. So those would be templates. How do you go about using them in applications, right? So I think building web components at one point is a good thing, but when you start to use them to build an entire application, it's a completely different ballgame. I mean, there's a lot of learning, unlearning, relearning that needs to happen. And I think for me, the first thing that started off was with the Shadow DOM. So Shadow DOM that looked so cool and nice initially actually became a problem for me when you're building an entire application. Reason for that was, by now we are used to using framework, we're used to using grid layouts, I'm used to using bootstrap foundation. I add the foundation file to my root, go ahead and write my DOM, write my classes, and all of them get applied. Because of this now Shadow boundary, I can't go into a web component and give a style saying column two medium or column three medium. I can't do that because it does not flow in. So that became like a big learning curve for us and kind of rethinking as to how we could go about doing this. And what we land up doing this is you essentially have a component file and you have a separate CSS file for every component that loads in along with that. So this is an example where you have a product listing file and I have a SAS file called productlist.scss which compiles into .css and I call that into the component file. And I kind of land up doing this for every single component. So I think that's one of the main learnings that we had with Shadow DOM. In fact, you could go to a state where now we don't think Shadow DOM is maybe not a right time for us to get used to. You could just work with templates, HTML imports and continue working with what you already have and then once you're more comfortable with the components and the Shadow DOM and then start implementing that. So that's one thing that you can consider. The second is using something called a master file or a base file or creating a file that contains the most common elements of features that are required for all your components. So in this master file that I have, I have a core media query component which is what I use for my mobile detection. That's also another interesting piece that I have right now. So I have a core media query component that checks what my max width is and if that max width is hit or not hit, it sets a Boolean on a flag called isMobile. So isMobile will just become zero or one based on the media query. So that's one component that I have on my master file. The other master file is something called as an HSD Navar. That's again a custom component that we all created. So it's a Navar component that will resize based on your browser, so that component. And every other component that I use, I kind of extend that in like this. It simply says extensive master file, which means all the properties, methods, and if required, even the DOM could come into this new component that I create. So you could try working with this concept of the master files. And the third thing, which is linked to the first and also this whole concept of responsive design. So because I was not able to use foundation or bootstrap in this particular example, we had to resort to how do we make sure that these components switch their views based on what screen size it is. So initially what we had, so if you look back here, we had this core media query that sets a flag on isMobile. And based on that, I can switch my templates. So instead of writing, instead of changing my classes, I could actually change my templates because of the shadow DOM. So here it says that if it is isMobile, then load the top part of the code. And if it is not, then just load the regular part. And I think this is good enough. Oh, yeah, the last one, yeah, the last one, sure. What happens with web components is you import one component that loads in a bunch of other components, and then that goes on recursively going and downloading a lot of components. And what you realize over a period of time is a very simple app that you've built has got a huge number of HTTP requests that are going all over the place. And that can screw up performance really bad. And the way to solve that is a tool called Vulcanize, again launched by Google. It's available as an NPM install. You can install it. And you could use Vulcanize My Elements and do a build. And it would take all your custom elements. It would go recursively going into all of them. Take all of them, take the HTML CSS, and all merge them into one single file. So essentially about 100 HTTP requests can just narrow it down to two or even one. So that's Vulcanize for you. So all that I just showed you, let's try and look that up as an example. It's from an app that we're trying to work with and build. Since I spent a lot of time on this whole e-commerce space, and that's where I'm more comfortable with, yeah, this is an example. Try to use Polymer as much as I could to try and build a simple product listing and a detailed page, try and get in those fancy effects, and try and make this whole thing responsive between desktop and mobile. So a very simple product listing page essentially makes requests to a JSON file and loads data from there. And this is responsive, so I could reduce this. And you could see the top now, but jumped into a hamburger menu. And these things would collapse. And then if I clicked on this, say, for example, it would kind of fade into this particular mobile view. And you could have these kind of crossfade effects and things like that. So all of these are kind of built into the component. This, in fact, is actually already it's available as a part of the core feature from Google Polymer. So I could go in and create these kind of effects. And if I extend this out, then it's based on that media query that I have, it snaps out, and it jumps back to a regular page. So still a work in progress. You could continue playing with this, but that's pretty much about the demo that I had and the code that we were using to work with this. So closing to an end, I think the real power of building applications going forward is using this whole concept of web components. The whole thing of we kind of redoing everything for every new project is really dated. You could go about creating web components, create a library of web components, keep that within your organization, keep it within your project, or even keep it within the entire community. There's a very good site called components.io, wherein a whole bunch of components that people are creating, they're uploading it over there. You can download them, use them, customize them, extend them, and things like that. And I think that's where the whole power of web components really comes in. And finally, how do you get started with using web components in your project? Obviously, component by component, right? You probably have a ready to use app. You don't want to, you can't go about saying, hey, I'm going to scrap this, I'm going to go and start an entire new project. You take certain elements from there, try and create them as components, add them back into your file, see how things work, where they break, go and fix them, and then gradually, you could probably convert your regular app into a components-based app. So that's about it. Thank you. Yes? My question is, here Polymer already is old now. I think material.angular.org already come, and they are giving that same type of feature. And Polymer and Angular integration is literally complicated, and performance issue is there. So what do you think about material, material.angular.org, whatever they launch? And they're saying this is very similar to Polymer as well. Okay, so these are three different things. Material design is more of a design language in terms of how you create various visual elements on screen. It has got nothing to do with Angular or Polymer. So I think that's one. It's a completely different design language, which talks about when I have a visual element, how does it look, how does it behave, how does it respond to various events? That's material design. So that's one. Second, Polymer is a library. It would remain a library. Angular is more of a framework. So you could try and correlate Polymer to more like jQuery, which is an element for creating visual designs, maybe a little bit of additional functionality, and things like that. There are examples where you're obviously using Polymer and Angular together. With regard to performance, there are multiple aspects that come into place. I mean, so you could have a degrade because of what? Because of multiple HTTP requests? If that's the one, then Vulcanize is a solution for that. If you're having performance degradation because of memory leaks, or if it's because of too many DOM elements on screen, then that's something that you need to look into Angular. So that Google? Because in the Polymer, the big question is basically the performance, because like you are making an enterprise application, and eight hours you wanted to run the same component as a task for the performance because memory leak issue in all is over there. So okay. So one thing about Polymer is it is still not, I wouldn't say it's production ready yet. So the version that you're working with is Polymer 5.5, sorry, O.5.5 is what we are working with. 10 days back is when they have launched O.8, which is a significant difference, or I would say enhancement from the current version. I mean, some of the videos that they talk about say that they have an 85% performance boost. The file size is reduced from about 200 K to about 15 K or something, really ridiculous reduction in price. And I think another Q2 is when they're going to launch the kind of the stable version of the production ready version of Polymer, and during that time they're probably going to be covering taking care of those memory leaks that you're referring to. But then again, like I said, Polymer is a framework or a library. You could still create a web component using the plain simple JavaScript and CSS, which may not have those memory leak issues that you're referring to. Okay. I have a question about here. I'm sorry, yeah, yeah. I have a question about CSS and web components. Is there any tooling available today to insert CSS from say my CSS or less code base into the component definition? Because since that DOM exists almost in a vacuum, I would hate to have to write code again over there. Somehow I would want that CSS to exist along with my main CSS code base. Exactly. So I think that's where the whole re-learning or this unlearning thing comes in. We are so used to writing our CSS in one single file and making sure that's available all across. With web components, that's not the case. You may want to re-look at it and say, why do I need to keep all my CSS in this single file? Could I not just keep them as separate CSS files, call them within the component level? So that's one thought approach. The other one, in case you really want to keep them in a single place, then you will have to use those pseudo elements like colon, colon, shadow or slash deep. Like I showed as an example there. So you could use slash deep combinators to kind of overread your shadow DOM boundaries and go all the way in and they'll affect all the components that are there on the screen. SAS, you can definitely use SAS. So in the example that I showed you, I was using SAS over there. But then the difference over there was each SAS file was compelling to its own individual CSS. It wasn't merging into a single main.css file like what we're commonly used to do. Just to add to what you said, if you're using SAS, you should be able to, like you can set all your variables and stuff in a separate file and include them across multiple CSS files or across multiple SAS files. So you can have the same settings and variables in the main application file as well as in the component SAS file as well. Yeah, that's true. So you'll be able to share that without any difficulty. Yeah, yeah, yeah. Thanks for bringing it up. So in fact, yes. So that was the underscore variables file that's there that's called into every other single SAS file. Thanks for bringing it up. So your variables and mixins can still stay in a single file. It's the final CSS that compiles that may not be as a one single file at that point of time. Yeah, okay. So Polymer does Polymer and web components does allow us to componentize all the three things that are DOM or JavaScript for that particular component and CSS. But there are cases when I do not want that particular component to be loaded at the first time. I do not want to organize and combine all of my stuff. It might end up being too large to download at the first thing. So when I end up downloading, when my view changes, when I go to some other stage, these things does not really emit the events which tells me that, okay, this particular element is ready to use. I end up using its attributes or try accessing the functions defined to that tag and they end up saying that it's not defined. Only the first time this thing loads or the page reloads, it emits the event that the Polymer is particularly now ready. But if I do it in a single page kind of app and I try to load the web component the next time, it does not emit the same events. Are you referring to the Polymers already? Yes, exactly. All those are there. Okay. Well, I haven't come across that. So what you're trying to say is- When my new view loads, it brings in new link tags that, okay, now load this particular component. When that particular component comes in, it does not emit that event. Okay. I haven't come across that particular scenario, but what I would, so these are these tags which are what? The common elements or these are- These are basically some element needed only on that view. So I wouldn't really require to load it at the first time. That would come in with that particular view. And if you set a timer of one or two seconds, it would be ready. Right, right, right. Then if you just try to have a direct access to it, it would throw an error. Okay. Well, maybe if you can have a look at it, probably you can try and work it out together, offline or something, but I wouldn't be able to. Hey, Vinci, so a quick question. I'm Arpan, by the way. Yeah, so regarding you, for to get it working with the responsive layout, you said that you were using multiple templates and loading a different template. But why didn't you just modify the CSS to do that? Like you can have the CSS for the web component itself to do all of that, right? Why load a separate template just for that? And how would that work if you were in a tablet or mobile where the screen was rotated, then you would not get the updated template, right? Well, it's essentially on screen width. So, you know, so I have, I'm defining, so essentially like the way you create media queries in your CSS for different max widths and min widths. Here I would just create, duplicate the core media query tag and set it for the tablet, this tablet, or is mobile, or is horizontal, except for different widths. With regard to your question on why can't I do that in CSS, well, yes, I could. But then what will happen is that I would have to kind of either use a slash deep combinator all across my page, all across my CSS, or in every CSS file that's relevant for each component, I would have to go and say, if media query 760, do this. Then in some other code for the other component, I go and do that, which essentially means my media queries are applying at a component level, right? And that's kind of like against the DRY principle. The second thing is the reason we're trying to use the conditional template over here is to also show you this concept that, so yes, in responsive design, many a times we would use media queries to, you know, realign the blocks, but at the same time, we are also having a fair bit of code that we kind of do show and hide, right? Like your hamburger menu or things like that, which are tabs, for example. On the desktop, you show them as tabs, but in a mobile view, it's more like an accordion. So sometimes I've seen people, they'll write chunks of DOM and they'll say do a show and hide based on media queries. So instead of that, I would use a template over here. So the template just loads in when required. I think there should be a better solution available. Yeah, so that gives me more flexibility also in a certain way, right? I'm free to change my layout completely different. Otherwise, many times with responsive design, you're bound by limitations of what you could do with your columns. So if you want to change the markup, then it makes sense to use a template, different template, but I think it is duplicating the template just for to be able to apply different CSS. I think it's probably a bad idea. Well, yeah, it is duplicating the template for sure, but the thing is because it's conditional. Sorry, I didn't have my mailbox open. So I think the way templates essentially work is they don't load up onto a screen unless they are called or they're registered. I'm not sure if you're aware of that problem, Mr. has a point. So one thing to remember about templates is any DOM that you put into a template does not get automatically called when you page loads. They'll remain inert. If you have images, if you have video, audio, they do not get rendered. It's only when a template gets activated or it gets appended to a DOM, that's when this component comes in. So although it might look like a duplication, but it's not really duplication of my DOM on the roots. Yeah, but what about if on a tablet, you rotate the screen, you're not going to get the right template loaded there? So I would write another if condition, like I said. So yeah, but yes. So these two approaches are perfectly fine. I just wanted to show this as a difference because we're all used to doing CSS media queries, but the template conditioning is something that I wanted to show. I'd try to play with it, so I'd try that out. Thanks. Thank you.