Have you ever thought about mixing two SPA frameworks together? In today's episode we discuss doing just that, Blazor and Angular running in the same application. Both Angular and Blazor have ways to export code as web components that can be reused in other applications. In order to use Angular in Blazor you have to get familiar with IJSRuntime and how JavaScript interoperability works in Blazor. We look at how Blazor can provide input and get output from Angular as well as discuss how you can handle CSS between the two. We also go over some of the use cases for using Angular web components inside a Blazor application. Have you worked with Angular Elements or Blazor web components? Let us know on Twitter at @dotnet_Podcast.

Hello, and welcome to another episode of Adventures in dot net. I'm Sean Klaiber, your host. And with me today are 2 co hosts, Wylu. Hey, Wylu. Good.

How you doing? The snow is finally melting, so I can almost see my grass. Alright. Nice to meet you. The cohost, Caleb Wells.

Hey, Caleb. Hey, guys. How's it going? Good. Good.

Yeah. We got down into the thirties today. Like, 33, I think. Right? Right above freezing with with rain, which is always beautiful.

But, I guess that's what you get in New Orleans. Right? You're not gonna get snow all that often. Has it ever snowed there while you live there? Yes.

Yes. It has. Yep. That's Okay. Once or twice, but it doesn't stick.

Right? It's just Yeah. Yeah. Yeah. You you see it coming down, but, yeah, it's it is rare.

But if you go to the North Shore, Mitch, right, we're we're in the bowl of New Orleans and you have Lake Pontchartrain to the north of us and the North Shore is suburbs. Yeah. They get snow every 3 or 4 years or so. It's just far enough north, I guess. But yeah.

Yeah. Nice. Anyway. Alright. So you're do you're doing a double duty today, Caleb.

So you're you're you're a cohost. You're also a guest. I think Well, you know, last a couple of times, so you you're probably good at it. Well, I think last time, you guys said I had some work to do, and you weren't sure if you were inviting me back. Well, I figured right while I did the last episode on the whole power platform.

So I figured I could I could take a stab at some Blazor stuff, which right. There there always seems to be something new in Blazor land because it just keeps picking up steam and momentum and new features and functionality and ways of using it. And so today, I actually thought we could talk a little bit about Blazor and JavaScript Interop. Right? And Okay.

One of the big go ahead. Yeah. I always say, so you we we really haven't covered that. You know, we've covered the basics and and new new features and things like that in previous shows, but we really haven't gone into the the interrupt part of it and, maybe working with other frameworks and things like that. So, yeah, sounds interesting.

Where should we start? So I think probably one of the reasons why we haven't talked about JavaScript interop and maybe it doesn't get as much fanfares. Right? The whole point of Blazer is to not have to do JavaScript. Right?

Or at least that that was one of his big selling points. But Yeah. So we so we should start off with when should you use interop? Well, you're going to have to use it in certain instances. So, right, the web assembly standard doesn't currently have, full access to the DOM.

And so that means you're gonna have limitations when it comes around things like geolocation or local storage, that kind of stuff. Right? And so what you end up having to do is you have to go through JavaScript through those. What I think most people don't realize is that in order to for your page to load and for the Blazor to get the WebAssembly, the Wasm, and all that, up and running, It actually talks through JavaScript to talk to the DOM to get all this stuff set up in the UI updated. So you're using JavaScript whether you realize it or not.

Down the road, as they evolve WebAssembly, which they're planning on doing and giving it more access and bringing it in line with JavaScript. Some of this will go away, but there are instances where where it's it's needed, and you're gonna have some form of JavaScript layer to get some of this functionality. Right? So the next thing when it comes to to this stuff is Blazor has interface for JS runtime, which allows you to invoke functions, make asynchronous calls back and forth. It allows you to to send and retrieve data, right, which you we're just doing behind the scenes in a way, but you're gonna need for this functionality.

And that led us to try a proof of concept, which has been done before, and that is taking web components and getting those to work inside of Blazor. And when I say web components, I actually mean the the HTML definition, which I can actually read it. Right? It's a set of features that provide a standard component model for the web, allowing for encapsulation and interoperability of individual HTML elements. And so the idea is you end up creating your own custom tags very similar to how you do it in Angular or React or Vue, and you inject those into the page the same way that Blazor does kind of the component model setup.

Right? So is it basically the advantage is of that is that it is framework? Yes. It is. Right.

It's like, you know, like yeah. Yeah. So that's how you can angle it. I also Blazor can Yeah. It's right.

It's basically HTML and JavaScript. And if necessary, if you wanted, you can bundle CSS in there too. And it's portable. The all the current browsers will recognize this content as long as you provide it the actual files to load that content, and it it'll work out of the box in any application pretty much. It's actually an interesting side note is that Angular IO, their website where they do all their their documentation and workflows, the majority of that is Angular web components.

And the reason being is you can manage this website and you can be a doc writer or do tutorials and not have to know necessarily how to build your own Angular app or all the intricacies that go into web component. You just know the inputs and outputs, and you can build stuff that way. And Angular calls this Angular elements. What it ends up being is a web component. So what we did was we already have several Angular applications running because we we have a couple of teams inside the company.

We have a couple teams that are contract, and the contract teams have been doing mostly Angular stuff. And so I don't think I've told you guys. We've got, like, between services and apps, we've got, like, a 100. It's a ridiculous number. They're wanting to consolidate that down.

And when I was hired, we decided that we want to move forward using Blazor. Right? Because majority of our internal team is is dotnetframeworkor.netandcsharpfocused. And Blazor gives us that that ability to be able to learn its version of Razor and then be able to use our c sharp knowledge and kinda, right, go to town. But we had to figure out a bridge between Angular and Blazor and or they wanted a bridge.

Right? For instance, if we have this, Angular application that has a bunch of components and we want to be able to reuse those until we can rebuild them in Blazor, how are we gonna do that? And we actually got a working model, which is which is really interesting because you end up doing, a deep dive into a JavaScript interrupts inside of Blazor. And so what you do is you have your your normal Angular components. They're doing their their stuff, inputs, outputs, event emitters, and there are certain steps you have to take inside of Angular to be able to export these, but you can export them as custom components, web components, and then you you reference the JavaScript, the polyfills, and the Angular code as well as your elements in at the bottom of your index.

And then you can reference those tags in any of your Blazor components. Right? And they could be as simple as an Angular component that takes an input. And when when the website loads, the Angular component is seamless. Right?

You have an Angular input, and you pass in a variable like your name into that the property on that tag. And when the the browser loads up, the Angular is transparent. You really can't tell just by looking at it what's Angular and what's not. And it's gonna show you your name that came from Blazor into the Angular component. Right?

And that's I guess by then, it's already a Yeah. It's a it's a web component at that point. Yes. Yep. Yeah.

And that's all fine and good. Right? But that's that's kinda got limited use. Right? Most of your Angular components are gonna be more complex.

And so, right, we had to actually do some tests where we're passing in, like, JSON data. Right? Or you get a call you call an API from Blazor, and you need to be able to pass those objects into this web component. And it's really interesting how how they've done this because what you end up doing is you have your own custom JavaScript where you can, right, you can build your own functions that hang off the DOM. And if you need to talk back and forth, you not only pass in this object, this data, but you pass in a dot net reference.

And it's actually called dot net reference, and it's a reference to to this component or the the contents of that Blazor component. And so if you say you have a chart widget, right, that's that's in Angular, and you like the way it looks and like the functionality, but there's functionality built into it. Right? You click events or filtering or whatever. Right?

You can actually have that loaded on the screen. And when you do button events, it's gonna emit those events. You're you're gonna have an event listener and just go trigger those events and actually return the data to Blazor through that dot net reference, and then Blazor can manipulate code outside of the web component to do whatever you want to do. So there's there's a lot of, power that's built into it. One thing that we're gonna have to figure out as we go, right, is our existing Angular components, they're not dumb components.

Right? They typically have a good deal of functionality, and they may be calling their own Angular services, right, using RxJS or whatever. And we're gonna have to look at how how we're gonna manage that because these Angular services, we're not gonna bring over. Right? They're they're not gonna be compiled into the component, and there's no way, at least that I found at this point, to to be able to manage them separately.

So we're gonna end up having to do those API calls in that state management in Blazor or in c sharp, classes versus doing them in Angular services. What what about the payload? Like, is each Angular element that you've converted to a web component have basically the entire Angular framework on there? You could. I wouldn't I would advise against it.

Yes. Yeah. Pay payload is something you have to factor in, and that's actually where when you build out the Angular elements, right, and you get your disk folder, you can determine how the JavaScript is broken up. And what I've done is I have, 2 JavaScript files that are strictly Angular based. Right?

The polyfills that it needs for certain browsers and then the Angular code, which is just main JS. Between the 2 of those, right, it's, you know, maybe a little over a meg. And then I have a separate JavaScript file that actually houses all of the web components. And, of course, that file can get fairly large depending on how many you have or you're you're pulling in, and there's really no tree shaking for that. But that JavaScript can then reference the separate polyfill in main and not have that that load every single time.

Now for each Blazor component you go into, that JavaScript, those web components are gonna have to be initialized. But in my testing, it's really there's really no performance difference between it and Blazor. Of course, we haven't done, you know, extreme edge cases or anything, but it performs well at this point. So So it's really the main use of it is just, for bringing over components that you don't have in Blazor? Could it be, you know, like, 3rd party components that they wrote it, for some for some JavaScript framework, like maybe some bootstrap components or things like that, and you can interrupt with those with Blazor?

Yeah. Yeah. If you if you needed to, you definitely could. Like like I said earlier, right, Blazor is growing leaps and bounds, and the the the additions they're adding to it and the features. So there there are a ton of components that will do, right, anything you could do or almost anything you can do in in Angular or React using Bootstrap or or whatnot.

But I do see this as a as for people who have a lot of SPA frameworks, a lot of JavaScript apps, and they want to transition. This is kind of a bridge, or it could be. The one of the interesting things about dot net 6 is some of the additions they've added to Blazor is you can now actually export Blazor components as web components and then reuse them in Angular or React apps if you wanted to or any app. Right? So it goes both ways.

But I see, right, they're trying to make it as easy a transition as possible if you want to transition, and you and the majority of your your developer knowledge is in c sharp. One of the other interesting things that we ran across, at least I find it interesting, but I'm also a a designer, a UI guy, is you can have an Angular app that, for instance, say, is using material design, right, in the material, NPM packages, and all that stuff. And you can actually change the styling in those components to use Bootstrap styling, but never install Bootstrap in Angular. And when you create the web components, you have Bootstrap running in Blazor, and you add that Angular component, the web component, it's going to pick up the Bootstrap CSS because it has the right styles and style itself appropriately for Bootstrap without Bootstrap ever being inside of Angular application and vice versa. You cannot have material inside of Blazor at all.

Right? Because especially with material for Angular, you can get beyond just the CSS. Right? They have their own web components that have JavaScript and all that extra stuff in them where when you click on an input, the the title or the the field goes up above the input. All that functionality, you can get that in Blazor through Angular without ever having to install any material stuff inside of Blazor application, which is is an interesting workaround, I guess.

If you again, if you're trying to transition, you're trying to match up styles between 2 disparate apps. So So do you see the use case of this as more like like like what you're doing? Basically converting, like, legacy apps into, to run on, like, new Blazor apps? Or do you you kind of foresee maybe, like, maybe you have 2 teams or one one team working on Blazor and then one team developing, like, new Angular, like, Angular components and all that stuff into and and turn them into web components? If that's second use case would work.

Yeah. I think think both are perfectly valid use cases Because alright. In a lot of cases, you may have a React app that you have no intention of converting to Blazor. Right? But then you have a whole separate team that's creating a new app, and they're like, hey.

We wanna do this in Blazor, but we wanna be able to use some of our existing components and and match the look and feel. Right? You could cherry pick and I'm not sure how React actually builds their web components or if they have they have that functionality. But in Angular, you can cherry pick the components you want and pull them into Blazor and vice versa. Right?

If you end up building this awesome grid in Blazor with with all the functionality you want, filtering, sorting, whatever, and you wanna be able to reuse it, you can reuse it inside of a React or Angular app. I do see this more as it's your code. Use it the way you wanna use it kind of thing. Right? And so the, I guess, the the possibilities really are endless.

It just depends on how your, like you said, how your teams are set up, what's your area of expertise, and where what's your road map road map is, where you're looking to go. And there's a few other things in Blazor dot net 6 that I think people are gonna begin to use more and more, become more common as people get used to to all the editions. Because, honestly, there there's a ton of changes in from dotnet5.net6. I mean, if you're if you're migrating, it's pretty straightforward, but the but the functionality that that you can do and and how you can segment out your JavaScript has changed. Right?

You can isolate JavaScript to a specific Blazor component. You can also now, with dot net 6, initialize some JavaScript before the Blazor app is even loaded. And Blazor knows how to take that that JavaScript, that content, and initialize it properly so you don't have to wait to get access to the DOM. So there's all kinds of cool stuff. I I appreciate the effort they put in to making Blazor work with JavaScript as as well as they have.

So I think it's the only way for it to succeed, to to be honest. Like, like, JavaScript's been around for so long. There's that such a big ecosystem of developers and and and existing components and all that stuff. You really can't get away with having a framework that doesn't interrupt with it versus seed. So it's actually really good to see it to see this happening.

Did you so what you're doing, is it like, it sounds like it's pretty cutting edge. Like, is this, like, based on, like, some sort of Microsoft kind of pattern that they published, or have you kind of just, like, experimented and just done your own thing and just So it's I don't think it's anything they've officially published. But, but like I said, I'm I'm not the first one that that came up with this. There's actually, Dan Roth, actually has a a GitHub repo out there that he dubbed Blangular, which is Blazor and Angular. It's 3 years old.

Mhmm. It's alright. It's it's fairly ancient when it comes to to development, but but it gives you the idea of how you get those to work. And I also found I found a resource on Think Texture where they they did something similar. And I I can add these links to the show notes for those who are interested.

But right. So so it was one of those things. I took a couple of odds and ends pieces here and there, saw how they did it, and was able to build on it to kinda meet our initial needs. I'm sure that's gonna grow, right, as we figure out the the Angular service stuff and RxJS. But it's been a it's been an interesting project.

It's been a lot of fun, and I actually have a proof of concept that I need to get up on GitHub. I just haven't done it yet because I gotta clean it up and, you know, remove all the company related stuff. So Mhmm. So what kind of lessons have you learned, doing this? You know, are there things that you can't do or things you have to watch out for?

Well, yeah. It's I guess, technically, there are very well, there I was gonna say there's very few limitations when it comes to this, but it's it's more of, being smart about how you use it. Right? I mean, you could jam 5 Angular components into 1 page and be passing all this data and stuff in and maybe the performance tanks because there's just too much going on, and there's just too much talking back and forth. Also, would recommend if you're doing this, right, and you you one thing you have to do with this is you're gonna have to write your own custom JavaScript to allow Blazor and your web components to talk.

So you're gonna have to know JavaScript if you if you really wanna get into this. And, suggestion there is, right, don't don't hang a bunch of far functions right off the DOM. Right? Don't use global variables. Don't I mean, all of this is common JavaScript stuff, how you you keep things clean and perform it.

Right? Create a create your own module hanging off the DOM and put all your functions inside of that. And, right, you're gonna have to keep in mind the not so much as the security implications, but, right, JavaScript and and Blazor, right, has our own access to the DOM, to the browsers. And so, you know, you might come across an issue where, you know, there's a mismatch there, and you're not getting the results or the look and feel you want. And and if that happens, then, yeah, you're gonna have some interesting debugging and and digging into your Angular app and making sure that there's no issues there and then how Blazor interrupts with that.

I do think maybe this is a little little bit of the wild, wild west. You know? It's you're kind of you you're rolling your own. But I do see the the the possibilities and the the functionality that you can get out of this, especially between multiple teams, to be worth the investment. So Yeah.

You probably don't wanna put your your angular elements into every row of a grid that's got a 100000 elements or something like that in there. So that's Agreed. Probably something not not smart to do. Right. So I think, again, like you just said, a lot of it comes down to common sense and knowing your limitations.

Because, right, the whole point is getting a quality application out to your clients or your users that has good performance with as little development time on you as is reasonable. And, again, I long term, I wouldn't wouldn't take an Angular app, export all these components to Angular elements, and then plug them into their own separate Blazor components and just call it a day. And, you know, and, hey. Here's here's your new app. You're you've got Blazor running, but it's really still just Angular.

I would take that next step and then convert those web components to actual c sharp laser components. But as, for us, I think it's gonna be a good bridge going forward. And it's interesting because the our contract teams actually did a demo last week or 2 weeks ago going over this proof of concept. And even though most of them are very familiar with Angular, they also have dotnetcsharpbackground. And several of them were like, man, I've been I've been looking forward to this.

So, like, when do we get started? So it's gonna be good. And I I'll keep you all updated on on the status. We'll see we'll see how it goes. And it sounds pretty exciting.

So sounds like it's, yeah, really cutting edge. It's fun stuff. Right? This I guess this is one of the perks of my job is I I get to go off on these adventures and and see what actually what actually works. And there were enough resources out there to get me started that actually, you know, worked well.

For instance, Dan's, which Sean added to the show notes. You guys will have it to to get it to where we can actually use it in a production environment and be comfortable with it. So Alright. Cool. Well, yeah.

Yeah. Definitely keep us updated. You know? We we only see you, like, every week. So so sounds good.

Alright. Yeah. You guys ready for picks? Sure. Alright.

I just gotta figure out what the heck my pick is. Preparedness. Preparedness. So, I'll go first, I guess. My pick is gonna be the new merger of Microsoft and Activision.

So it's gonna be interesting to see, you know, how that goes. You know, I'm I'm a big Blizzard fan. I like Diablo and things like that, so be interested to see what happens with with those projects and where Microsoft takes it. But it's nice to see Microsoft kinda going in there head first with the game stuff now. Well, you know, they've $59,000,000,000 there, right?

That's, I can't believe they're worth that much. Well, no. I I think they probably overpaid, but they can afford to do that. Right? And they they bought Bethesda the year before or the beginning of last year.

So there there is there there's a bunch of questions. Are they gonna add World of Warcraft to the Xbox game pass? And are they gonna port it to to console and all kinds of stuff? So time will tell. Right?

But, yeah, I think it's cool. Yep. Alright. Why would you pick? So this week, my pick is actually the Amazon Fire Stick, which I kinda just picked up because it was, like, really cheap on my Amazon Prime thing.

And it's like I don't know. I don't even know why I bought it because I've already got an Android TV thingy. But, like, it's just, like, so much better than the Android one. Like, it's so much smoother and Yeah. So I think maybe because my Android one was actually pretty old and it was a little bit like flaky or something like that.

But, yeah, I'm really enjoying the being I've never actually been near the Amazon kind of ecosystem kind of thing. And yes, it feels like the look and feel of it's a lot more mature than the Android one. So yeah. Cool. But Cool.

Alright, Gil. Have you came up with a pick? I have. This is actually a food, a foodie pick, and and and it may be a southern foodie pick. I don't know if you guys have ever had French onion dip, like, with potato chips.

Right? My family were were big snackers. And so, right, we we like potato chips or Fritos. And French onion dip, right, it's it's like sour cream, but it's a it's a dip that's got its own taste. And not all brands are equal.

Right? They're not they're not all the same. And the best, French onion dip I've ever had, and sometimes could be hard to find, is called hell of a good dip. So my pick is, hell of a good dip. So if you haven't tried it, you should try it.

If you can get it in Australia, why let me know. Okay. Yeah. Does it go good with veg does it go good with vegemite? I don't know about vegemite, but, you know, hey.

If you wanna use celery instead of chips, if you wanna try to be a little healthy, celery works too. Alright. Cool. Alright, Caleb. If you, people have questions and they wanna ask you questions, like I said Yeah.

Ask you questions about questions? I think I think I have a a Twitter account, out there somewhere. It's, Caleb Wells Codes. Alright. And, you know, if, you can you can get on GitHub and ping me on one of my repos.

I'm also on LinkedIn. I think all my stuff gets thrown at the bottom of the show notes, but I'm all over the place. So yeah. Hey. If you have any questions and and I can I can, help, I would love to chat?

K. And if our listeners have, feedback for the show, they can reach out and get in touch with me. I am on Twitter. I am at.netsuperhero. Alright.

Thanks, Caleb. Thanks, y. Yeah. Yeah. Nice job.

Alright. Yeah. We'll catch everybody else on the next episode of adventuresin.net. Bye,