React Day Berlin

React Day Berlin 2022

It's Time to De-Fragment the Web

Sami Jaber

JS Nation

JSNation 2022

Immutable Web Apps

How's it going, JS Nation? Today we're going to talk about immutable web apps and dependencies. First, I'm Andy Damaris. You can find me on pretty much all the social medias, at Teradox, and my website is teradox.tech. So what we're going to cover today is we're going to start with the problem. There was a problem that we were having at Meltwater, and then we'll move on to immutable web apps, what they are and why we're using them, dependencies without bundling them, referencing those dependencies, and then last we're going to talk about how we or those dependencies successfully. So what's the problem? Well, the problem was dependencies. We had a lot of them, and they were being created by internal teams for libraries that we could use on a regular basis for things like authentication or companies lookups or users lookups, and each of these things was beginning to compound the amount of duplicated JavaScript that was being bundled together with all of the different applications we were shipping. So we needed to figure out a way to unbundle these dependencies and allow them to be shared more effectively between the many applications that were using them. So immutable web apps were an important part of that journey, so we're going to cover those first. The basic philosophy of immutable web apps is that you want to build them once and deploy them many times. There are some really specific fundamentals that we need to accomplish in order to be an immutable web application. The first one is all of our environment variables need to be outside of the bundle. This allows our bundles to be built one time per version and be immutable for that specific version. They'll never change after the first time they're built. It also means that we need to deploy them to a URL where the version that we just built is included as a part of that URL. So we want that fully qualified URL to have our version number in it somewhere. Now what benefits does this really buy us? There's a bunch. The first is that when we're testing in staging and we're testing in production, they're using the exact same assets. The only difference will be the configuration that's changed between the two. This means that all of our assets can also be maximally cached. They can be cached for a full year, in fact, which is the current browser maximum. There's a huge benefit to our customers for that. They only ever need to round trip for that specific version of that specific asset once. And after that, it's on their local disk cache, saving huge amounts of time for secondary and tertiary loads of the site. We never have to worry about them having to go back to origin constantly for these large assets at times. The other things that get included with this are you always know which versions are deployed because your index HTML page makes it very plain. Look at your script tag, what versions in the URL? That's the version you're dealing with. It also means that rollbacks are now really trivial. We're just flipping back from one specific version of a set of assets to another specific version of a set of assets. And if you're a consumer already, chances are good you already have that previous version of assets in your disk cache ready to go. So you won't even have to pay download costs again for it. So we've talked about all of our assets, but what about the index page? Well, the index page is the one part of an immutable web app that you don't cache. It's our focal point for where all of our changes are allowed to show up immediately. So we like to break things down into three different thought processes. You don't have to break it down this way. It's just an exercise in a way to think of things. So the first piece is just our static web hosting, right? It hosts our index HTML page. That index HTML page is pretty static. There's not a whole lot of dynamic nature to it. And it dictates the versions of all of the static assets that we're going to deliver. Those static assets are then delivered using script tags. And those script tags use the fully versioned URL that we were talking about, in this case, version 1.2.3, to be able to deliver those assets. Then we also have our APIs. And our APIs could be on a different server, could be on the same server. But we dictate which API we're going to hit by that configuration block you're seeing in the script tag. That configuration block tells our application where we should go to hit that API and what the route should be, removing that environment variable from our JavaScript code. So I've glossed over immutable web apps pretty quickly here. There's some more nuance, a lot more detail that you could dig into. And if that's something that's interesting to you, please check out immutablewebapps.org. So now let's dig back into the main crux of what we're talking about, which is dependencies. We have a lot of them. They're being used by a lot of different applications. So how do we fix that problem? Well, we're going to need some tooling to do this successfully. The first little bit of tooling we're going to use is UMDs. They're a specific type of bundle that we'll dig into. And then we're going to talk about HiMyNameIs, a tool for helping us discover dependency names. And then we'll talk about Orchard, which is really our tool for ordering those dependencies. So the first tool I want to discuss is UMDs, the universal module definition style of bundling. Pretty much every bundler out there supports it. And it allows those bundlers to give a specific name to a package of code that will then end up on the global disk scope in the browser. The benefit of this is that now we can reference that module using the global disk namespace that it's occupying in order to bring it in without having to bundle that dependency into our other code. The example that we're going to work with today is Meltwater Visualizations. And you'll notice that when we're talking about making a name for this UMD bundle, we include that suffix of a V major version. In this case, major version 14 of Meltwater Visualizations. The reason for this is that when we reference a major version, it allows us to potentially load multiple major versions of the same dependency in the page at the same time. Now you might be thinking that that feels like a bad idea, and I agree with you. But there's also benefits to being able to do that. When you have a lot of intertwined dependencies, not all of them are going to be able to move at the same pace. Upgrading a dependency for visualizations to version 14 when other people are relying on version 13 might mean that everyone has to upgrade at the exact same time and do a very large forklift upgrade. But if you can load Meltwater Visualizations 13 and Meltwater Visualizations 14 at the same time, you give those other teams an opportunity to upgrade at their own pace, at a reasonable pace that makes sense for the workload that they're under. And that means that versions can move more slowly. And instead of having to do a forklift upgrade, you can now upgrade versions when they make sense to do so for your team's movement. Now, this doesn't mean you shouldn't be mindful of a lot of duplication of code. That's how we ended up here in the first place. But it does mean that it makes that upgrade path a lot smoother across a lot of different teams. So how do we use UMDs within our bundle? Referencing them comes down to bundling tools. We'll start with Webpack. Webpack has a property called externals. Externals allow us to load those UMDs that have been put on the global disk scope by referencing them using their module name. By using their module name, it tells Webpack, I don't want to bundle this node module anymore. Instead, I want to make a reference to that node module to this corresponding global disk namespace. So a couple of things are happening here. One, Webpack is being told to ignore bundling that module name. And two, that module name is being set up to correspond to a global disk namespace object that should exist. The benefit of doing it this way is that when we're testing with something like Jest or Beat Test, we can still use that node module to be able to run our tests. It doesn't have to reference the browser-specific code if we don't want it to. This means that our testing and mocking is much more straightforward than if we were always relying on the global disk namespace. The benefit there is easier test setups, easier to debug, and your local code runs the way that you would expect to. It's wonderful to know that we can just use the NPM module for local testing and know that that will act the same as when we're deployed. Now let's look at what a rollup config could look like for this. In rollup, those two things we were talking about that Webpack handles in the externals get divided out into two separate configuration options. The first one being which modules are not going to be bundled together with us. That's what the external property is for in rollup. It says, here are the modules, I just don't want you to load. You don't need to bundle those into my bundle. And then we can down in the output globals option, use that same type of map we saw in Webpack where we reference the left-hand side as the module name and the right-hand side is the global disk namespace that we want to resolve for that module name while we're bundling. It has a very similar output in the way that we are referencing these things, and it makes it very straightforward to reference UMDs from the window object. But if we start thinking about when we get to 20 or 30 or 50 of these dependencies, maintaining that config is exhausting. There's so much to maintain. Every single one of them has a major version we have to keep track of. When we upgrade our package JSON, that major version could change and then we have to remember to update it in the config. I mean, it gets to be a bit of a mess, but luckily we can automate that. And we can automate it through a package called, HiMyNameIs. This package is going to be open sourced hopefully within the next month and you'll be able to take advantage of it. HiMyNameIs is basically a library that allows us to build out that module to namespace mapping that we were talking about without you having to maintain that yourself. And it does it with two very straightforward functions. The first function is called generate namespace from package. Generate namespace from package allows you to build that global this namespace we were talking about, including our major version, so that we can populate it into a new package JSON property. That package JSON property is called browser namespace. This property gives us the ability to resolve that information later in the build. So once you've got a library that's using this and building out that property and package JSON, it means your consumers are now set up to be able to successfully reference them. Let's look at what that looks like. The second function out of HiMyNameIs is get package namespace mapping. This function goes to your package JSON for your project and looks at all of the dependencies. It ignores the dev dependencies and resolves those dependencies to look at their package JSONs. If the package JSON for that dependency has a browser namespace property in it, it uses that to build out the mapping of module name to global this namespace. So you don't have to maintain that anymore. As you're versioning, it'll just get versioned for you. Every time you build, this will resolve appropriately in a very rapid manner and give you that mapping that you need. So in Rollup, it's a little bit more complicated, but not much. Similar to with Webpack, the get package namespace mapping function still gives you that global this object, but then you also need to build out that external array like we referenced earlier. Luckily, the get package namespace mapping has all the information you need to be able to do that successfully. Okay, but we still haven't tackled ordering, right? And that's a much harder problem because dependencies can have dependencies can have dependencies and they all need to be loaded in the right order in order for this global this resolution to work appropriately. But we can automate that too. That's where the Orchard CLI tool comes in. It very similarly to hi, my name is reads your package. Jason looks only at your dependencies, ignores dev dependencies. But instead of stopping at the shallow level, this time it uses a package directly out of NPM JS called Arborist to build out the full dependency tree. Arborist is basically behind the dependency tree resolution for things like NPM install. It allows NPM install to build out that full dependency tree to understand what new packages need to be put where in that dependency tree. It helps build out the package lock Jason as well. So very powerful tool that we did not build in order to make this system function. Using that dependency tree, it then builds out a set of script tags based on that dependency tree resolution. And then we limit that using a curated set of yaml files. Why a curated list of dependencies? Well, there's a couple of reasons. The first one mostly is safety. We don't want just any package being loaded from node or loaded from NPM. We really want to limit it to just things that actually we want to be loaded into the browser. By limiting that, we're kind of limiting the number of things that can load to a very specific subset that we actually care about. It also helps by limiting that dependency tree resolution to a much shorter amount of time by trimming branches that are no longer relevant. So with these tools in place, we have this yaml file now that we need to worry about with the orchard. Luckily, it's a reasonably straightforward yaml file. Here's what one looks like for an internal dependency. At the top, we have ownership information. It's wonderful within a large organization to be able to know exactly who is responsible for the dependency that you're relying on in production. That's a part of what the orchard allows us to keep track of. Each of these yaml files has an owned by, a repo, and a contact property that allows us to keep really close track of who is actually in control of these different dependencies. Then under the technical details, this is where we're actually building out the path for each of the dependencies that we're loading either via script tag or link tag. We split it into these three parts for a really specific reason. We wanted a suffix that is the base path that these things will be loaded from. Then we wanted a version path that allows that version path to be maybe prefixed with a V or an at symbol, depending on where it's being loaded from. Then the suffix is the specific files that need to be loaded. In the case of what we're looking at, this would load a script tag with type equal module and then resolve out that base path plus the version plus the ESM path as the source for that script tag. It would also create a link tag based on that, once again, that base path, the version, and the CSS path to build out that link tag, allowing us to create a set of ordered dependencies. There are two other properties in here that are worth calling out. One is conflicts with other major versions, which is that call out before of the fact that we try to make sure that our internal libraries can run with multiple major versions at the same time. This would be the spot that we would kill a build if two different versions of the same library were trying to be loaded that cannot interoperate successfully. The last one here is requires initialization. There are some internal libraries that require you to run some initialization code in order for you to be in an appropriate state. We like to call that out for our consumers so that they know exactly what they need to bootstrap. Looking at an example for an external dependency looks very, very similar to an internal dependency. In this case, Moment.js. We can see that the ownership stuff has shifted a little bit. It's no longer an internal concern, so we don't have things like team names, but we do have things like the repo that it came from and where I can go to contact them if I need to in case of an issue. The technical details are also very similar. In this case, you can see that we're using ES5 instead of ESM because there isn't an ESM version of Moment.js. All that means is that instead of being a type equal module script tag, we'll now get a script tag with a defer on it, which basically allows that script tag to be deferred until after all the DHTML has been parsed, and it will follow the same ordering process as a type equal module for when we're doing that resolution. You'll see here that we have conflicts with other major versions set to true. You can't load multiple major versions of Moment. It's just not allowed. They occupy the same global this namespace and would overwrite one another. That's a couple of examples of YAML files that are used to configure the orchard. I want to take a second to talk about some of the outcomes of doing this work, the benefits that it's provided us at Meltwater. The big deal here is it's a good thing. It's really helped us cut down on the customer issues that we were experiencing. By having staging and production be relying on the exact same versions of the code, we no longer worry about logic changes that could sneak in between staging and production. We also have decreased our bundle sizes overall for our application bundles by making those dependencies external. Those dependencies can then be relied upon by many different applications across our application suite, since they're all loaded at the same domain. We've also seen that caches are getting hit much more often. We're seeing a lot fewer requests for upstream files, since they can be cached so heavily on the browser. It's really helped a lot with user load times. A quick summary of everything we've talked about today is we had a problem with a lot of libraries being loaded in a lot of different applications and that duplication of JavaScript being downloaded. We took an immutable web apps approach to making sure that all of our assets were versioned fully and maximally cached. We build them using UMDs, which allows that global this namespace to be created. It can also be loaded via the bundlers that we're already using. And then the little bit of tooling for DevX is HiMyNameIs to allow those dependencies to be resolved more quickly and more easily. And also the orchard. The orchard is responsible for loading those things in a specific order. So I covered a lot during this talk, and I know there were a lot of topics here. So thank you for your time. Thank you for listening. And if you have any questions on any of these topics, definitely reach out to me on social media. I'll do my best to respond as quickly as I can and answer any questions you have. Thanks so much again for your time. It was great being here to speak.


Andy Desmarais

Web Components are awesome!

Hi, I'm Dwayne, a JavaScript developer advocate at Vonage, and the good folks at JS Nation have given me 10 minutes to make the case on why I think web components are awesome. So what are web components? Have you ever used the video, audio, and or details HTML tags? Ever wondered how just by putting the tag with some attributes and properties you get fully working media player interfaces with volume controls, play and pause buttons, and more or a drop down that just works out of the box? Now imagine creating your own HTML element that does whatever you want it to do. What does the browser support look like? All modern browsers have support for web components. You may be saying to yourself, that sounds cool and all, but are web components a thing yet? Luckily enough, it's a website. And the answer is yes, that's it. Just kidding. This site lists some companies that are using web components. And as an exercise for everyone watching, as I scroll down, if there is a company or logo you recognize, say ding. Here we go. It's a long list. Seen anything yet? The list keeps on going. There's quite a few. And this is just some of them. How many times have you said ding yet? Keeps on going. Here we go. Now here's a couple of specific examples. If you view the source code of YouTube, you'll see many HTML tags that begin with YTD. YTD is not a normal prefix for an HTML element. So that's a good clue that it's a web component. Now when you do things like creating a repo, pushing changes, and or merging PRs on GitHub, you can see how long ago your activity happened. Those are web components. And GitHub is offering them for everyone to use in their own projects. Now I like to make websites. A lot of websites. For each, I like to have an about page that goes over the who, what, and why I made the site. Now creating the page over and over again became a chore. So I created a web component called Dwayne-made. I can pull the data about the website from an endpoint in the project and pass it into the web component and Dwayne-made knows how to display that data. It saves me a bunch of time to focus on the application itself. Another awesome feature is that a web component can have multiple uses. For example, isn't it cool how the humble input HTML element can do so many different things with just a change of the type attribute? So along those lines, I made Dwayne-timer because I was dealing with a lot of time and dates and personal projects and didn't want the hassle with it over and over each time. Not only can it display a date and time local to the visitor of the site, but it can also be a countdown timer just with an addition of a property to the web component. Now the tooling around web components is pretty awesome. There are so many libraries and frameworks to create web components. Want to use TypeScript? There are multiple libraries you can use. More familiar with JSX? No problem. A good resource to give these tools a try without having to download them is webcomponents.dev. Now webcomponents.dev can do a bunch of things, but it can also give you the templates to where you can just kind of kickstart a web component to kind of see if it's what you like as far as coding. Right now there are 64 templates that you can use. Now if you are on a team and want to ensure consistency across all the web components you build, there is Open Web Components which provides guidelines, recommendations, and best practices when creating web components. They also have a CLI tool that will scaffold a project so that all web components will have the same file and folder structure, making it easier for every team member to get up to speed on a component they have never seen before by knowing where to look. Now the fact that there are so many people working on web components means that there is probably something already built that is similar to what you are looking for. No need to start from scratch, which is awesome. Webcomponents.org is a good place to start to see what's out there and even add your own to the list. I'm a big fan of WebXR, augmented and virtual reality on the web, and always wanted to create an application but didn't have enough experience to be able to create something from scratch without studying a long list of different technologies like 3JS, 3D modeling software like Unity, and so much more. That's where the Model Viewer web component comes in. It does everything I need to do to display a 3D model in both virtual and augmented reality and more without needing to know the underlying technologies that went into making it work. With it, I was able to create a WebXR tic-tac-toe game with voice chat in about a week. Here's a quick demo. Now as you can see on the laptop to the left, I have the 3D version of the web component, the actual tic-tac-toe board. On the right, I have the augmented version of it. I'm able to pass the moves back and forth using Vonage APIs. Also I can enable audio chats and that's also done through the Vonage APIs. So you can see the moves are being played back and forth and then at the end when there's a winner, there's some confetti. So if you want to give it a shot, you can give it, you know, play a game or two. I have it deployed to XOXR.games. I'm hoping to add more WebXR games to it as well in the future. Now another awesome thing about web components that you can use them in your favorite framework or by themselves. This site, custom-elements-everywhere.com, lists how well supported web components are with various frameworks and libraries. So let's take a look. There's a quick scroll through. Now just take a note of your, see if your favorite framework or library is here and how well do they work with web components. It's quite a long list. There's a lot of different libraries and frameworks that this website uses and tests. All right. That's enough. You can check out the website itself if you like to see if your favorite framework is on there. Now I created a set of web components to be used with the Vonage Client SDK. Each one knows what events to listen for and what events to send when needed. So they are a straightforward way of using the Vonage Client SDK regardless of the framework you choose. Now I've written a series of blog posts on how to use them with Angular, Vue, and React with more coming soon. Not only can you include them into your application, but you can also style them to look like a part of your application. Here's an example. This is the VC text input from the Client SDK UI web components I mentioned earlier. So here's the default styling. If I uncomment this, you'll see it changed to a totally different styling, which is pretty cool I believe. So I think that is awesome. Well there it is. Just a few of the things I think make web components awesome. Thanks for listening. Hopefully, you think web components are awesome also. Now here is a link to my web components blog series. My contact info is on my website, lifelong.dev, if you'd like to discuss web components or anything Vonage. Check out our APIs if you want to add some real-time communications to your application via video, voice, text, SMS, and many more. If you found them to be awesome and want to learn more, you can check out our APIs. Once again, thank you for listening and have a great rest of the conference. See you around.


Dwane Hemmings

React Advanced

React Advanced Conference 2021

Let's talk about Web Components

Jemima Abu

React Finland

React Finland 2021

Web Components in React

Matias Huhta

React Summit Remote Edition

React Summit Remote Edition 2020

Bringing Ionic (and Web Components) to React

Hey, everyone. My name is Mike Ardington. I'm a developer at Ionic, and I want to talk to you about bringing Ionic over to React and then go over some of the fun challenges that we face along the way. If you have any questions, feel free to reach out afterwards. For those who don't know, Ionic is a framework for building cross-platform apps using HTML, CSS, and JavaScript. You write your app using our components, and you get a native iOS, native Android, or desktop app or progressive web app, all from the same code base. Roughly 20% of all the apps in the app stores are using Ionic to some degree. Now that is kind of a vanity metric. Doesn't really mean anything, just that people are using Ionic and having a lot of success. As well as being used inside of the app stores, there's millions of developers all around the world using Ionic today and being very successful. Now a little history lesson, Ionic had been historically tied to one specific framework from its very beginning. And as frameworks kind of come and go, and JavaScript as an ecosystem matures, we constantly heard from our developers that they wanted to use more than just that one framework. And to be honest, we were interested in seeing, can we bring Ionic to other frameworks as well? But we constantly were afraid of having to rewrite our components to yet another framework that could or could not last for the next five years. Now fast forward to last year in 2019, Ionic had had years of stable releases. And JavaScript as an ecosystem had matured to a point where there was a lot less turn through different frameworks and different standards. And we were feeling pretty ambitious that we could create another binding for a different framework and support something more than just what we were historically tied to. So in about six months time, we ended up creating an entire collection of React components based on our original Ionic component set. These are all components that you can import and add into your standard React project and followed React best practices internally for how to manage component state and provide all the different interactions that people would expect. More interestingly, we were able to integrate with React Router and start to create a higher order component that could create animations and transitions automatically for you without developers having to wire that up themselves. Now that leads us to Ionic React, which has hit its stable release a few months ago, but brings Ionic to even more developers out there. So let's take a look at what Ionic React looks like. Here in my editor, I just have a standard React project, and I'm going to open up my root app component. Now we have a collection of different components that we are importing from Ionic React, as well as a wrapper for React Router and our various components that we can route to. We also include the core Ionic CSS, as well as our own custom theme in variables.css. Now further down in our app, we have our core app component with a IonRouterOutlet, which acts as a placeholder for all of our different routes. For example, we can route to tab one, tab two, tab two slash detail, as well as tab three. We can wire up how we route to those components by looking at the different tab buttons inside of our app. So let's open up one of the components for this tab interface. Here in tabs two, we have yet another standard React component. If you've been using React for any time, this should feel pretty familiar to you. One piece that does stand out is this Ion button on line 28. Here we're wiring up a route link using the router link property. In our app, we can navigate to the tab two by clicking the tab two button, and then click the go to detail page to navigate to detail. What's interesting here is that tab two is now independent from all the other individual tabs, creating a stack navigation that can be maintained through different tab changes. In another example, we have what we call linear navigation, where there is one place for your app to load routes. Here we have a music player app that is loading songs and albums off of Apple Music, and we can even search against Apple Music using our search page component and typing in a query. Now this app is an example of a Progressive Web App deployed to a browser. If we wanted a native iOS app, the same code base can be deployed to a native iOS project and loaded up and run on your phone or simulator. If this sounds interesting to you and you want to try it out yourself, you can simply install the Ionic CLI using npm or Yarn, and then run Ionic start to create your app. Our CLI will prompt you for an app name and then your framework of choice, as well as a starter template to get you going. Wrapping up, Ionic and React make a great pair together. You get the simplicity of building apps with React, plus the high quality components that you get from Ionic. You can ship as a Progressive Web App, and then when you want to target iOS or Android, you can add those native projects as you need them. This really gives you the ability to reuse your existing web skills and learn once to write for any platform. Thank you. Well, that's a lot of knowledge in just 20 or 28 minutes it was. Four great topics. I would, yeah, I would like to invite all the lightning talk speakers with me on the stage to do the last round of Q&A of the day. Hey everyone. Hello. Hey there. Hey. Hello. Good morning, evening, night, whatever it is for you. Yeah, I'm going to go straight into the questions. I'm going to start with the first question for Matt and Claire. What market are you targeting and why would someone use Mux instead of Twitch or YouTube? Yeah, it's a valid question. We're a developer facing product, so we're purely just APIs for developers to build into their platform as opposed to Twitch and YouTube, which are much more consumer facing products. So if you're a streamer just looking to go live without writing any code whatsoever, those are great platforms you should probably use them. If you're trying to build a platform, we're probably a better fit there. Okay. So it's more about the target audience, I guess, and that you have more control over what you're doing. Yeah, I would think about it a little bit like a bad analogy that I mentioned in Slack is they're more like the PayPal or Venmo. We're more the Stripe, if you're thinking about it in terms of payment APIs. Okay, thank you. Next question is for Jen. What are the reasons why someone like the React Native web team would want to use a div as a button? The reason is that putting HTML inside of a button is not actually semantic HTML. So they may want to wrap that content, for instance, a card or a block of an image and text into a div and make that an accessible button instead of putting a button around it. Yeah, so if you have a completely clickable card with different elements inside it, you can do that semantically within a button. Correct. So in that case, you'll want to make an accessible div. Well, you should want to at least. Perhaps. And can I say, if you don't, Jen is going to come and get you. I will very kindly tap you on the shoulder and make suggestions. How about that? Yeah, but tap doesn't work. Then I might have to. Yeah, yeah. Another question, but just for you a nice tap on the shoulder from Martin van Houten. Not really a question, just want to say Mesh looks awesome. Well, that's always nice to hear. Thank you very much. I hope that after you try it, you'll feel the same and not hate me. Well, actually, at the company I work for, Albert Hein, we are using it. And I have to say it's been a pleasure. So thanks a lot. Oh, I can come visit you. Yeah, it would be a pleasure. Mike, does Ionic support native apps similar to React Native or is it like a Cordova standard app where it's a web UI instead of a native app? So it's kind of a mix of both where the majority of the UI is displayed in a web view. But you can integrate with custom native views or activities on Android and kind of mix which one gets displayed, either the web view or the native view, or even just overlay the native view on top of the web view. So you get kind of the best of both worlds. That feels powerful. OK, thanks. Thanks guys and my lady for these great talks. For the people watching, they're also going to be in the Zoom rooms for questions. But the formal part is now over. I'm going to say goodbye to you for a little bit. So thanks for joining. Thank you. Thank you. Bye bye.


#web components