Hey, everybody, thanks for coming to another episode of Adventures and Angler.
I'm the host Aarreon Frost, and on our panel we have Brian Love Hello
in Europe, in Wales, women Wales, and I should say as the
well say hi aii. You know that's what they said to me, Hi
Hi. All right, that's cool, all right, and then that's all
on the panel today we're paneled light right, it's a lot of pressure on
Brian, that's all right. For our guests, we got Thomas Hello,
you want to go ahead and introduce yourself? Sure? So, hi everyone.
My name is Stormstram and yeah, I'm a Google the Open Expert Angler
contacting in Switzerland, working on open source writing loo post trading angler stuff like
this. How'd you say your last Namely, it's not my real name.
It's just like the online Oh yeah yeah, I didn't know, yeah,
pseudonym. Yeah yeah, it's like it was like very long time ago,
like when I was creating like my first Gmail account, and then somehow like
I created all the accounts based on that, and I was kind of too
late to switch it back, so I kind of stick with it. So
what's your real name? It's Tomash. Hey, Hey, okay, yeah,
hery, where's that from? Basically it sounds German, but like I'm
from Slovakia, Okayah. In the Middle Ages, they were actually like a
lot of German like migrants into those areas which is now in Slovakia because there
was like a lot of like silver mines and stuff like this, and also
there was like this black plague you know, which killed like three quarters of
Europe and then kind of it was like all empty, so they were like
running around and like repopulating. So the yay, let's go over there late
West, Let's go back to the West. We went to parties. Yeah,
I'm coming back all right. Well, hark alight, it's easier.
That's confused to people, is the Okay. So you're kind of an expert
on in your elements, right, like a web component things with angler.
Yeah, well I'm not would not say like expert, but let's say I
spend like quite some time lately like working with elements and like trying to figure
out like how to use them the best way and stuff like this. Right,
Brian, do you think he's an expert? You know, he looks
like an expert. I mean, he looks pretty serious. Yeah, I'm
gonna say, I think you're an expert. I don't think many people have
done a lot with uh with web components and stuff. So if you spend
a serious amount of time, I think that you qualify as an expert.
It was like back when ja query started, I had dorged around with it
for like two months, and people were like, oh, a gentleman is
an expert. That's a very good metaphor you kind of auar elements expert for
right now and for right now, that's a very good designation, like for
right now, for this very sure. But anyway, like I think it's
right, yeah, yeah, because it can. The thing is like it
can really solve like some some use cases and some problems which are like very
hard to solve the otherwise, let's say, so they can be pretty useful
in those kind of situations. Are some of those situations that you're using any
of your elements for? Yeah, right, So so the thing is like,
I mean, if you if you're working like a huge enterprise organization with
tons of developers or let's say tens of teams and hundreds of developers, then
usually you have a couple of options, right, So either you are building
like some crazy model of it, and that most people and organizations realize that
this doesn't really go anywhere, or maybe you go like very fancy and like
you go for like a model reports. I was listening actually this morning a
podcast with or something actually the Adventures in Angler about modern reports, and many
people do that. But there is kind of like also a dis thurd way
where you can go like for kind I call it like multi SPA. So
you have let's say twenty to fifty or even like US eighty plus applications and
they kind of look the same, and they are basically integrated using a standard
HTML hyperlinks, and if they are like fast enough, then for users it
can be pretty simless experience. Right, So you do one flow in one
and another another one and you continue here and there and it all kind of
works. But usually in case of this kind of solution like multi SPA,
it happens to be so that there are like some components which are used across
many of those spas. Right, So let's say let's imagine like some document
doc here where you need like to browse some documents for like the case or
something like this, So and then these kind of reusable components or like kind
of sub applications are usually implemented using like library, like a standard legual library.
So you can do it nowadays with agular coli of ENGI packagery, of
a great build. Everything is amazing, and I mean you can have like
even a very good CI pipeline. So basically whenever you release a new version
of the library, it can trigger like a build of all the consumers.
So you basically rebuild all these pass and maybe you even deploy them into like
some test environment. But I highly doubt that all this organizations can continuously like
deliver every of those up like to the prod, like with every little change.
So usually some of the newer apps they go like straight through, but
like there is always like some legency, maybe like some hybrid aps. It's
not like the green field if it's like some big organization which exists for like
a decades. So and in that case, what can happen is that some
of those consumers applications of that library will not be deployed and you will get
multiple versions of that library in the PROD, which may or may not cause
problems depending on the APIs and so on and so on like let's say,
or complicate your back end dramatically because it has to support multiple versions of like
the API to retrieve the data because this library could not have been like released
properly. Or even if you have let's say, like some state synchronization between
those sputs like because of that component, this can cause serious problems because if
the component or like the state which is holds changes, it will not be
compatible and stuff like this. So these are like some real life problems which
I encountered in these kind of organizations. And this can be really solved with
elements, So it's kind of specific. Then again, I can imagine that,
like in this basic organization is not so rare. Let's say, Yeah,
I just wanted the people listening to know that when he said eighty apps
on the page, he said it with a straight face. Yes, sure,
I was here you're talking about I've heard this term kind of thrown around,
and I've seen a couple of talks about it, but I still can't
honestly wrap my head around it completely. But there's this idea of like micro
front end architecture, right, And is that what you're kind of referring to
when you talk about having like multiple apps all on the same page, run
at the same time. No, no, no, So this is a
very good question because so microfront and is like you have a one shell and
this loads multiple SPUs and we will get to that later. Okay, so
that's like microfrontas that's like the most hip thing and like depends, but sometimes
a great way to do things. Sometimes it doesn't match. What I was
speaking about is like multispo So like to reiterate that, imagine you have like
eighty standalone Angular applications who live on their own context, got it? Okay,
right, you're switching between them exactly, and as you follow the business
flow, you switch between them. So they in isolation can be small,
maintainable. You can throw them away or implement them with React or with view
whatever as you want to evolve, or with web components or with Angular fifteen
who knows, like how old it gets. From the consumer point of view,
they look like one huge portal, but actually those that are independently deployed
applications, and currently we have more than eighty of those, let's say,
and then if those applications share those components, is when it can happen.
Yeah, right, So now I'm loading up those components every time. There's
no caching, and I can have multiple versions. Yes, so the cashing
maybe that's also kind of an issue, but usually you have a good network
in the enterprise environment. But the problem is these multiple versions. This can
really like make your day a bad experience when you are dealing with side kind
of like synchronization bugs. Then like this is a bit older kind of state.
And then like to get the overview because you know the version of the
of the apps or the applications themselves which are deployed, but do you know
every version of every sublibrary of every deployed application stuff like this, so it
gets pretty complex. That's the name are exactly. So we will build like
some kind of like custom dashboard to actually track these kind of things. But
yeah, in these kind of situations, you can really get a big wins
using elements because once you are using an element or like any kind of web
component basically doesn't need to be angular element. But I mean angular element is
like just just easier to reread than value of web components. Suddenly you don't
have a dependency on the library, so you actually don't need to rebuild anything,
and the component itself is deployed as element somewhere as a bundle, and
those consumer applications just consume it as a UURL. And because it's like this,
if I deploy this document DOSIA or whatever that is as a new version,
all these pass will get it immediately because the urals stayed the same.
So my question is I'm sitting listenings and I'm thinking I don't need this necessarily,
right, but some people do. So what's my lateness test? Like
what questions can I ask myself to be Like OI, should I listen to?
Should I do what Thomas is talking about? Like? What are the
things to ask yourself? What are the scenarios I can look forward to say,
OHI my bed time to get into what Thomas is talking about. That's
a very good point. So for this thing in particular, Like the first
question is am I in this multispast scenario? So I am having multiple independent
applications running which kind of look the same and are implementing business flow which you
just like switch from one up to another. So that's like the first thing.
Second thing is if I am in this scenario, are there some components
which are shared across these applications? Let's say like a document editor or like
a let's say customer profile or something which is kind of always the same and
provides this context in all those applications. It's always the same, but like
you know, you have to display it in these various contexts. So and
in these kind of cases this may be a good approach. Another thing which
we were exploring is like every application has like this header right where you have
like some basic stuff like alerts and like maybe like some tasks for a workflow
for employees and stuff like this. This also usually is always the same in
all those applications and can communicate just by like passing some small context in terms
of like okay, this is the case ID or stuff like this. So
how does this compare to So you listen to Victors who came on our show
and talked about mono repos and how it can share code using libraries, and
you know, they've got this fantastic tool I've used and Victor was kind of
really talking about called an X and now that makes it possible to do some
of this. How does what you're talking about compare Like, why did you
perhaps or the companies the clients that you're working with she used to go this
route versus like a mono repo and can you share a little bit of that
backstory with us. So the thing is also what was what Victor was saying,
is even if you have mono repo and like let's say you use it
with not about ethics, and then let's say you just rebuilt and the retail
is like the affected things based on the dependency graph, as he said,
like the deployment and the like the like creation of the artifacts and then like
the deployment of the artifacts. It's kind of like two separate things in the
narmal world as far as I remember. So basically, as you run your
built, maybe you rebuild the affected projects based on library change, and then
the artifacts gets to some repository whatever can be docta imagis can be just like
zip files whatever that is. And then there is kind of like the separate
process where you decide like when to release stuff. Even if you use mono
repo, and if you don't have like synchronized deployment cycles of all these applications,
you can get the same problems. So you still can get to a
situation when some application was deployed and some not if you deploy everything always,
you will not have this problem. If everything is done with the feature flags
only and you always go with everything to pro you will not have this problem.
And that would be a solution in terms of like our organization where I'm
currently helping. The decision was based also based on like experience and already like
the kind of workflow they were having, and like there is a momentum over
a couple of years and so on and so on, so like they didn't
really have this freedom. Okay, let's now do a total revolution and like
go with NX. Got it. So their starting point was like this huge,
huge monolith. It's like all these eightiespos were basically inside right, and
then like the first first step was kind of like modulized. Then take it
apart to make it at least a bit maintainable. And who knows, like
what the future holds about it's like all nice and modulized. Maybe it can
be brought back into mono Apple, we will see. Tell us a little
bit more about how you're using angular elements in these scenarios and and all these
products. I just also want to be clear all the projects that you're talking
about these eighties spots. They're all Angular applications, right, yeah, not
like mixed with react or view or so now, no, it's timesler and
like angular jas and hybrids. Got it? Okay, So I just want
to make sure that I'm understanding what you're saying you're doing, just to make
sure we're clear. You have like one app that's kind of like the shell
maybe the header and the footer, and then you're loading different apps in the
main content or no, no, what are you doing? Are they different
ur ls entirely or what is going on? So I have the same origin
and I have different than after that, after slash, I have different contexts,
and there is like some proxy and those are eighty standalone Anglar applications.
That is, so like my app dot com slash A, my app dot
use the editor case product whatever that is, Okay, multiple spats, and
they implement business flows that we navigate from one another using hyperlinks because they all
live on the hyper links. And just so I understand, each hyperlink will
do a full page load to another SPA, right, Okay, Okay,
I'm understanding. Okay, But because it's Angler fast enough, because modern Angler
can start like in subsecond times, it's like five hundred milliseconds and basically if
you put some static template which kind of look like this original layout, so
that's not a problem. And you're doing this for enterprise, so that people
are doing this from workstations on like a network connection. Okay, Right,
so you've got a bunch of different spas that link to each other and they
use similar components. So if I go to like the you know, the
first SPA, it might have the same button in the same model from every
other SPA. Yes, but I would say it's more like on the level,
not like of these atomic components like a button, but more like on
components customer profile or like a case or like a document editor, so something
like a bigger chunks or bigger chunks too. Yeah. Yeah, instead of
sending someone over to a different spot for their customer profile, maybe I just
have one customer profile component that can be used among the multiple spats, because
it's usually for these kind of things which you need contextually very often just to
be able to do your work. Yeah, and then I'm guessing a lot
of on top of just component sharing, you're probably also sharing services to do
the communication with the back end. So in that particular case like this.
As I said, this component is kind of like bigger. So let's say
let's concrete example, like it's like this, this document does here, so
like for a case or for whatever reason, contextually needs some documents. So
and this is implemented using Angular elements. So this is totally self contained.
It has its own backundary services, it has its own interceptors and stuff like
this. Yeah, and all it needs is to get like some small context
from the parent usually like some case idea or stuff like this. And maybe
you can pole the case idea out of the URL. Maybe I don't know,
right, like just patent pass it through like a standard component input.
Yep, yeah, you're an Angular element, okay, exactly. And I
have this this customer profile component like this big reusable Angular element. Right,
it's kind of self contained with its services and knows how to do its own
AHTTV interceptors. So I have these big, reusable, shareable components. And
to Brian's question, Brian's like, well, why don't you build this with
NX so that the customer profile gets built into your bundle. But what you're
saying is I don't want to include it in the bundle. I want to
deploy that Angular element to its own URL, and then you just load it
real time as the website loads. You don't actually bring it in at build
time. You load it at runtime for the clients. So those are the
two main differences between what actually last week. Last week was Victor right,
Ryan's right. So that's kind of funny that we have these two kind of
I'm not I don't know if they oppose each other, but they're different elementary
complimented. I would say, the other kind of approach that I've seen,
you know, I know, we want to get into kind of how you're
actually using this and you're using these structural directors and stuff. The other proach
that I've seen, and Victor briefly mentioned it is, you know, because
you're all all your eighty spas are all Angular, you could go the route
of like, oh, I'm actually going to create a library, like an
NG library, build that and then publish that up to artifactory or a private
MPM repository and then consume that. Again, it would be bill time,
but you basically consume that by importing that into your NG module and the imports
right and say bring in this module that does the customer profile, and now
I have that app h customer profile valuable in my Anglo application that I can
use. But you're not going either of those or two approaches. You're saying,
let's go with an element that's a customer element, and then we're not
even really relying on Angular exactly. So what you describe was our starting point,
okay, the standard library, and we imported all those consumers and during
the build time it was integrated and that was working quite well. But then
there was this problem that even though we could guarantee that they all get all
these consumers with this newest version of the library get deployed, let's say,
to test environment at the same time, so we don't have any compatibility issues,
not all of those applications go exactly at the same time to plot for
various reasons. So it's not like perfect continuous delivery or how to call it.
Well, that makes sense. You can't deploy all the spas at the
same time, right, That wouldn't make sense. You kind of could if
you had really like a perfect process and perfect like feature toggling and all these
kind of things in like ideal world, maybe you could. But at least
in our organization. This is not the reality. So some things can go
to straight there, and some things are like let's say released once a week,
that's like the longest timelts. But with your approach, I don't have
to deploy the spas together because the spas, they're all loading the component from
a real a single production location. So the second I deploy my element,
all the spas, whether they've released in the last year or not, are
gonna get my latest thing right exactly. So I'm gonna tell you why I
like this approach and why I think it's good for some scenarios. I feel
like Thomas, you've embraced the intention of the Web Component API. The Web
Component API was made, I think, to load bundles at runtime and not
necessarily webpack them in at build time, and so I think that you've embraced
that intentionality of that API better than like an nx Mono REPO bringing in at
build time webpack scenario. Right, So I like it. I think it's
good in some scenarios, not all, but in the scenarios where it fits.
I think this is a fantastic idea, and I love that you've wrapped
it up so that other people could use it, because these are hard problems
to solve, right, And I love that if I get in that scenario,
I now know you've walked down that path and have a production ready app
that's kind of gone through a lot of the pains I might have ended up
in, like instead of having to set my dumbster on fire accidentally, maybe
you've kind of solved some of those. There are some fires too, there
are some fires sold else. That's cool. I like this different approach.
I think it's a good idea. I think cool. As you said,
no, like there are different requirements, different environments with different histories, and
like if you're starting fresh, maybe you can go for one thing when you
have like some like history and like some environments which you cannot just like imagine
it's not there. Maybe this can help. It all depends, And it's
as you said, like it's always good to have multiple options to approach like
a single problem, so and you can just pick what seats are the best.
Cool. I think this far in the podcast, we've done a pretty
good job. At least I feel like I understand what you're saying, and
I hope that we're breaking it down on levels. We're all level. Engineers
of all levels can can understand this. So my question is it sounds like
you've bundled this up and it's ready for you people to share what you've done.
If I wanted to get in on some of this action, where can
I go to learn more about kind of what you've done, as we didn't
really get into details yet, but basically like to do this, you have
like kind of two options. So if you build an element and you serve
it like from some URL, you can basically include a script tag with a
URL in your like head section of your page so that it means it loads
before you start using that tag in your templates and your components and your consumer
angler application. And that will just great, but this may make your startup
time worse because it's all this extra javaska we'll have to load. So and
because of that reason, I basically build a library, which makes this very
lazy and like as lazy as it's possible, because it kind of waighs for
loading of this bundle to the latest possible moment, which is when the component
tries to render that element, so it can be not just with the routing
that like, Okay, I go to some route as it's usually standard with
Angular, it can be just hidden behind the ng if for example, so
when it's behind the end, if it's not rendered an until you kind of
click on some button or some other kind of interaction which says that condition in
the ng if true, which renders that tag, it will be postponed.
The loading of the element bundle will be postponed until that time. And this
was implementing the library called Angular Extension Slash Elements, which you can find like
on githop. And it also has like a dog's website with like examples where
it can play around. So what it does is like you can basically there
is some showcase where you like can load in this kind of way like material
web components or like ionic stuff or like some stencil built stuff, any kind
of web component which lives on some UL basically so you can play around.
And there are also like some contributions already for community. Because it started like
very simple that basically pass the URL of that element bundle into the directive which
does all the work. But this was kind of annoying when you kind of
wanted to use an element which is repeated multiple times, and then this erl
was like this long string like in your template multiple times. So there was
already a couple of community like pull requests which for example, add the feature
that you can pre configure URLs for the text in your module. So you
can have like a lazy elements module for feature, and you say, okay,
my document editor teg will come from this you and stuff like this.
There are even like more stuff coming. So for example, we want to
add a flag that it's possible to set each of those element bundles should be
preloaded, for example, or like let's say we want to specify that when
the element bundle is loading, you want to show like a loading template,
so let's say some spinner or in case it fails, we can also show
like some error template. And this is already possible, like to specify the
directive itself, but we also want to add a possibility to specify this globally
for example. So let me ask a question because I'm seeing I'm seeing a
scenario where in a really complicated multi SPA enterprise scenario where you have a leg
up over over certain kind of the other way the web back way of doing
things. So let's say my SPA I'm on Team A and we're building SPA
A right, and our spot A is going to use your customer profile component,
right, and we're going to load it as a remote web component like
what you're talking about. You know, if Team A, if we're building
Angular eight, we haven't upgraded to nine yet, but your customer profile component
is on nine already. It's okay to have mismatched versioning because it's it's an
encapsulated app. Is that true? Or am I wrong? Or is that
true? You're right, it's totally isolated. In that scenario. I'm ensuring
both A I don't have version conflicts and b everyone has the latest version of
the component regardless of where that the app is deployed recently. That's true.
Yeah, So the only only kind of issue my encounter is related with like
the zone JITs. So if you're writing like a new anglad Element scratch,
I would highly recommend like to goes all less. And if you're writing something
new kind of can if you are converting already existing Angular implementation to Element,
which is also a valid use case, there are like some possible pitfalls like
relating to zone jays. So basically it's it's very contrived like things coming together
at the same time. When basically you kind of your element has an input
and your apparently is setting some values to that input, and that's all right.
This works perfectly. And let's say then you are displaying that in your
template in your element or do some stuff with engine on changes, this also
works perfectly, no problem at all. The problem starts when in that on
changes you basically emit a new value of a stream, and let's say that
new value of a stream will be then transformed into a back end request,
and this back end requests will give you some value in some times short time
in the future, this will not trigger and unfortunately because that stream will run
in the parent zone, not in the element zone. So this is something
very very specific. Like I basically open the issue on Agua repository on GitHub.
I was discussing this with the Gli Passion or passion or how we pronounce
the guy's name, who is kind of like the maintainer of Zone Jays,
and he bent very like in depth on that and explained why exactly this happens
in that issue and that he will like explore further like how to deal with
it the best way. But momentarily, what he recommends is in those kinds
of cases, what you can do is to share the parent consumer application engie
zone with the element, so you can basically pass it to the child and
all these problems disappear. So this is also what we are doing, and
this is also documentary on the doc website, where is also the link to
that kidab issue. If you are interested in the intricate sis of like elements
zone and addicts how they come together, you can explore that there. If
I wrote an on push and my input changes, and I funnel that input
into a stream into some RX thing that's going to go to the back end,
and my component has on push turned on right for the change detection strategy,
then when that HTTP request comes back and I've used the acinc pipe,
I should re render. So I wouldn't have this issue if I do it
that way, right, So there's ways around what you're talking about. True.
So unfortunately, the thing is like even if you use on push and
even if you use acink pipe, actually what ASIN pipe does is there is
like this internal call like change detection mark for changes, but actually it doesn't
work without the zone. You still need somebody to trigger the detecting of changes.
So like, if you don't want to share let's say the parent zone,
which is also possible, you can basically include a workaround which will call
explicit change the texture change detector detect changes method. So marking for changes is
not enough. You have to do exactly. This is exactly the reason why
even if you used one push and acid pint, which kind of should work,
will not work. Like we try that. Unfortunately it's not the case.
So I would need to kind of defensively programmed in streams. Yeah,
I probably need to use some tap that does a change detection, forces the
change detection exactly. Yeah, that's the one way to do it. Yeah,
sure, yeah, so yeah, that would be like a second option,
like if you don't mind this, like instead of like sharing parent zone
like because maybe well, I mean, if your if your parent is not
angler, you don't have this problem at all anyway. You get wrongs only
if there is no zone, so that's okay. But yeah, if your
parent is angler and you don't want to share zone, you can still do
this and explicitly trigger change. I mean, ultimately, if this section is
only happening you know once in a while, and by one time once a
second, that's really not that big of a deal, right, Like,
especially if it's only once per back in request, like that's not gonna happen,
but once every two or three minutes, so exactly. So in our
case, it was like only once couple of minutes when basically the context changed
and we had to load like a different customer profile or something like this.
So this can be even once every ten minutes or something like this. So
that's not the performance issue at all. No, no, but I can't
imagine cases where it would be. All right, we got a few Oh
wow, wait, do we just get the voice of a ghost? Who
is that? Hello? Hello, it's Peter Baker Darwin. Who is that?
It's Shy coming to your life from my car in Israel? Oh nice,
welcome. Continue continue you're in the end of the episode because thanks for
stopping by though. All right, So my last question was the Angular elements.
I think it's found a great home for like NG upgrade. Like if
you're trying to upgrade an angular jess app and you're trying to do like a
bottom up approach, and so you you know, build the bottom leaf nodes
in angular and then you wrap them into angular elements and then you consume that
with angular jests. I think that's found a great home there. I haven't
heard of too many other people using it because currently the size of those elements
is huge because you have to bring in Yeah, and if you even do
the router link in the most router, which is huge, and like the
angular elements right now are just big. I'm guessing you've done some looking into
IVY to say ivy's going to change the angular elements story by x How does
IVY affect what you're talking about, like my concern about the bundle sizes.
Okay, that's very good point. So first of all, like currently let's
say Angular seven or eight without iv like when you start, like you start
like at around one hundred and thirty seven kilobytes like Hello World. So depending
on the use case, maybe too much, maybe not too much. But
as you said, like once you start adding stuff like router and like your
own libraries and whatever that is, then it can grow, like just like
HTP client and the whole HTP module, HTP back and stuff like this.
But the truth is like, yeah, if you like, if you are
like in this kind of enterprise, environment and you end up like around three
hundred four hundred kilos, it's not such a big deal. Plus if it's
laidy loaded, lazy loaded and is cashed by like the server and stuff like
this, it's kind of okay. But yeah, like for other use cases,
more like in public Internet, this could cause issues. So the IVY
will make this better. So the thing is there is like this amazing article
from Monfreschtire who kind of goes in depth on that. So the thing is
currently in Anglar, we have this helper function which is called like create Angular
element or something like this. So basically passing a component and this helper function
will do all this heavy lifting for you. That it basically wraps that angular
component as a custom HTML element, so it has to do all these like
bindings between attributes and then the component inputs and know when to trigger the change
detection for example. Also a very big feature. What it does for you
is it enables you to pass also complex objects, not just like primitive things
like strings and numbers, but it alls to pass in objects and stuff like
this. And this is done currently, but this is the old style.
This is without IVY and basically the elements will get much better once this helper
function creates angular element from a component is implemented using ivy, which will be
an upcoming feature most likely. And this article which I mentioned from like montford
Shire is basically explode how this could look like. So he kind of rites
it by hand, this wrapper with the help of Ivy, and then he
gets like to I think like fifty kilobytes got it. Yeah, And one
of the things that like Frost he was bringing up was like, you could
have angular elements that are different versions, right or maybe ones on nine,
ones on a, ones on seven or whatever it is, you would likely
still I mean even with ivy I guess Ivy's future anyways, but you'd still
be paying that bundle size because you've got to bring in the entire run time
right of Angular whatever that is the should be client or whatever you're doing the
route. And so if you've got these different versions, you've got this issue
as well. But what you're kind of saying is in an enterprise scenario,
maybe this solution is a win because it saves money and allows teams to work
together and all this kind of thing they can develop in isolation. Yeah,
they could exactly isolation without how multimillion dollar deploy system to do all right kind
of deployment cycle. And plus like you have a caching so actually cashing of
element cannot be like with standard edgediplication because usually I have like this hash in
a file name, but the element bundle has to always be called the same,
so you can have like a stable link, right, So and to
do that you basically have to implement like e tax on our server. So
if you are I don't know how people know like the e tax, but
basically it's the way where you make like it is tiny, tiny request like
the ETag hash which was calculated for you beforehand to the server and the server
tells you okay, this this change or not. So in enterprise scenario,
usually you get cashed after the first request and then it's just your cashed or
it's just a three or four not modified response exactly exactly. So this is
not really a big deal if you don't have like these millions of new users
every day. If it's just this recurring couple of thousands which get cashed very
fast, and then it's like no problem. Yeah, one thing I would
like to mention before we end, Like so this solution has we spoke about,
like it's like for this kind of like a sub application. But actually
what is also possible nowadays, like this library which we discussed, is to
do like a proper microfrontens and to enable that. Like the biggest problem with
that was if you even if you layserloaded the element, you still kind of
had to hardcode that element into Angular templates. You had to say, like
my document editor, and then okay, you could dynamically set the UURL where
to load a bundle, but you already had to like commit to that that
in this place, in this template there will be a document editor or something
like this. And this kind of sucks because with the micro front ends,
maybe you want to make it really like configurable so based on whatever, what
kind of user, what kind of customer, what kind of context you want
to load different apps. So and this was not really matching that well.
So there is like this new feature which kind of is a bit hecky,
but it's kind of possible because the directive takes it away from the from the
real dome. It makes it into template. You basically can dynamically set the
tag name and when it it puts it back, it will be that new
tag which you configured. So for example, document editors, you start like
with a deef or with a span or whatever, and once when you put
it back, it certainly will be like my organization document editor and this works.
This works in Angular and the browser will pick up that teg as a
custom element and instantiated and everything works. So this really enables you to do
fully configurable micro frontains where you can even like load the configuration from the back
end or like even pass it like however you like, and then basically build
it up through euros and custom tags wherever you want. So this is already
available today using your Angular elements or excuse me, Angular dash extensions for such
elements package right, yes, hackey in a way that like, I don't
know all the implications of this, all the all the implications that's all tested,
but give it a try. No, No, it works. It
works. That's not a problem. It works. I just don't know if
it could break in the future because it kind of depends on how Anglar does
Megie templates. Ah, Okay, so it's tightly coupled to the way Anglar
does Engie templates. Let's put it that way, gotcha. Gotcha. Yeah,
that's funny. All right. Well, Thomas and some people listening are
going to gravitate to this, you know, they're going to feel the need
for each other. So where can we go to find out more? And
where can we go to get a hold of you? Right, So,
if you want to like discuss these kind of things, just pit me on
Twitter, like at Thomas tryan. And the library itself, like of course,
is on the kitab so it's like Anglar Dash extension slash elements and that's
also like the website, so okay, like a website is also hosted on
GitHub, so it's Angular Dash Extensions, dot kitup ioslash elements. I guess
we can put the link like the description of the of the podcast so that
they can just click on it. But if you just if you just google
for Angular Dash Extension slash elements, you will definitely find something and there will
be more links. Okay, can you put that into the show, into
the chat on the right, of course, and then can you also link
to your Twitter account because we want to make sure people can get a hold
of you. Right. So I think that was great. I actually learned
a lot and I appreciate that you came on and took the time to break
this down for me. To be honest, before we started, I didn't
understand the benefits, but you you peeled it back in a way that I
actually now understand why this would be super beneficial. So I'm going to go
ahead and give this a try because I think I have a scenario where this
might this might work. So I appreciate you coming on and checking it out.
So thank you very much, man, thank you very much. Happy
to hear that. Let's get on to the picks, Brian, you got
some picks you want to go first? I do. I got to pick.
My pick is No to Atlanta and Angie Atlanta coming up in February,
so I think tickets just are on sale now, so if you want to
check that out, you can go online and grab your tickets for our next
year's event. Note Atlanta, Yeah, which is combined with Anglan. If
you are going to Angilanta, Angilanta I think is Wednesday, Thursday, Friday,
and then not Atlanta is going to be Monday, Tuesday, Wednesday,
and so there's going to be a full stack day in the middle of the
week. And if you're doing note on the back end and you're doing angler
on the front end. This might be a conference for you to kind of
check out. That sounds cool. Oh, the voice is shy hunting you.
Awesome. I've been listening all the time I've been here. You're watching
us. He's behind you right now. Don't you have any picks, bro,
I have one pick. So my pick is a medium blog ofsan l
Basal, which is an Israeli Angular blogger, which is just finished the meeting
with is a good friend and he writes tons and tons of really really valuable
articles on Angular and also does a few open source projects. So I will
put a link. I will write you when I get back home, Frosty,
but it's Nathan L and b A S A L. That's my pick.
Thanks man. I appreciate you freaking us out and reminding us that you're
always watching. That's awesome, all right. So my pick is, uh.
A lot of people will remember kind of react Gate from a few weeks
ago, and one of the things that came out of there was some books
that that some people said to read books in the react that's interesting. Yeah,
so they yeah, they said read. You know. Tatiana Mac was
like, hey, read some of these books, and I I felt like,
yeah, I need to read some of these books. One of them
is my pick. It's called How to Be Less Stupid About Race and it's
on the show notes page if you want to go check it out. But
I'm reading this book and like chapter two, I'm crying, and it's a
real kind of I don't know, it's an awakening of sorts. It's a
hard book for me to process. But it's a good book, I think
for a lot of people to read, especially if you live in a country
where people think racism doesn't exist anymore, or racism continually is getting downplayed.
This book is fantastic. And I'm at a point where I realized, I'm
realizing right now everything I was ever taught about race in America was not true.
And it's hard to process that. Like, but it's a good book,
is all I'm gonna say. I'm gonna let other people make their own
conclusions. But great, great books. So that's where I'll leave that.
Thomas, do you have any do you have any picks? Right? So
to lift it up a bit or maybe not, Like, so the thing
is not like I grew up like in the in the nineties. Let's say
I was the teenature and at that time, like there was like this shut
out of music like called new metal. So maybe some of the listeners are
like acquaintance with that, so like stuff like system of down Corner and Slipnote,
and the thing is like Slipnotes, Like the band just released a new
album like twenty years after and it's actually really epic. I was so surprised,
like they still like really have it, at least from my subjective point
of view. So if you are a fan and you didn't listen to it
like in a long time because it's kind of like old, give it a
try and see, like if it still does for you too, the new
slipnot. Yeah, I really like that. Well, Thomas, thanks for
coming on. I had a good time. I feel like I learned a
lot. If anyone has any questions, head over to Twitter reach out to
Thomas. John is t R A J A N. It's just Thomas to
John Thomas, without an h just tm as asking questions. He's super responsive.
He's one of the Angelo g ds who really loves engaged with the community,
so feel free to to pulverize them with questions. So so, yeah,
thanks for coming on, and Brian and Shy thanks for coming on.
And remember always remember I'm watching you, whoever you are. And listen there
I'm watching you. Yep. No and TV listeners, we'll say thanks for
coming and until next time, peace, peace,