1
00:00:06,759 --> 00:00:10,519
Hey, Welcome to Adventures in Angler, the podcast where we keep you updated

2
00:00:10,560 --> 00:00:14,679
on all things Angular related. This
show is produced by two companies, Stop

3
00:00:14,839 --> 00:00:18,640
and Devs and Onvoid. Top and
Devs is where we create top and deves

4
00:00:18,640 --> 00:00:23,280
so get top and pay and recognition
while working on interesting problems and making meaningful

5
00:00:23,320 --> 00:00:29,079
community contributions. An Onvoid which provides
remote design and software development services on a

6
00:00:29,120 --> 00:00:34,399
performance basis, so clients only pay
when the tests are delivered and approved.

7
00:00:35,000 --> 00:00:40,039
In today's episode, we will talk
about migrating to the new Angular features.

8
00:00:40,520 --> 00:00:45,079
That means all the tooling, all
the new features, and the caveats of

9
00:00:45,119 --> 00:00:49,560
how to migrate your current cod base
to the latest version. Is it really

10
00:00:49,640 --> 00:00:53,679
that hard or is it a smooth
transition. My name is Lucas Baganini.

11
00:00:53,759 --> 00:00:57,799
I'm the founder of Onvoid and you're
hosting a podcast. Joining me in today's

12
00:00:57,880 --> 00:01:06,280
episode is Charles Maxwood, Hey,
everybody, and Armand Vardanian. Hello.

13
00:01:06,319 --> 00:01:11,560
Everyone. That's too bad for another
one, okay, so let's get into

14
00:01:11,599 --> 00:01:19,319
it. Armen again, you are
are experts on the subject. You have

15
00:01:19,400 --> 00:01:25,359
been researching a lot about the new
features on Anglar seventeen. So let's start

16
00:01:25,400 --> 00:01:30,959
with the biggest concern that people have. Is it hard to migrate to Angler

17
00:01:30,040 --> 00:01:36,760
seventeen or is it a smooth transition? Oh yeah, that's really the most

18
00:01:36,799 --> 00:01:41,439
important question. And you know,
I would be very happy to say that,

19
00:01:41,519 --> 00:01:44,799
you know, it's sorts super easy, But I don't like creating Yeah

20
00:01:44,959 --> 00:01:51,680
we're done. Oh no, I
don't want to create illusions. Of course,

21
00:01:51,799 --> 00:01:56,359
it's it's a hard one to crack. And there's a bunch of stuff.

22
00:01:56,439 --> 00:02:00,000
Like it's not one thing that you
can you know, just do overnight

23
00:02:00,359 --> 00:02:05,599
or maybe you just cannot allocate like
some fixed amount of time and say Okay,

24
00:02:05,599 --> 00:02:07,840
I'm gonna upgrade and I'm gonna have
all the latest features and so on,

25
00:02:08,199 --> 00:02:15,240
because it involves a bunch of stuff. What I would definitely say from

26
00:02:15,240 --> 00:02:22,159
the good parts is that the Angular
Core team did their absolute best to provide

27
00:02:22,199 --> 00:02:25,919
the best possible experience when transitioning to
these new tools. We have a bunch

28
00:02:25,960 --> 00:02:30,280
of schematics, we will talk about
them. You can run and get lots

29
00:02:30,280 --> 00:02:37,000
of things automated for us. There
are a bunch of resources, there are

30
00:02:37,000 --> 00:02:42,800
a bunch of approaches that one can
adopt. And of course I know lots

31
00:02:42,800 --> 00:02:46,919
of the personal frustrated now because you
know, most of the Angular folks are

32
00:02:47,120 --> 00:02:53,639
stuck around Angular twelve to fourteen,
and even the guys who have like Angular

33
00:02:53,680 --> 00:02:59,400
fifteen or sixteen, they actually have
the latest version but are not using all

34
00:02:59,479 --> 00:03:07,719
the latest features because those features also
require a lot of manual work and a

35
00:03:07,719 --> 00:03:14,840
lot of testing. So yeah,
it's a step steep place to approach,

36
00:03:14,960 --> 00:03:20,199
but with the tooling we have,
and if you doube the right approaches,

37
00:03:20,719 --> 00:03:24,520
it's definitely possible. So it's not
that hard, but you still need to

38
00:03:24,520 --> 00:03:30,240
be careful. So yeah, we're
gonna talk about that, and let's talk

39
00:03:30,240 --> 00:03:37,599
about in which versions it becomes hard. Because I recently upgraded many projects from

40
00:03:37,639 --> 00:03:44,000
sixteen to seventeen and that was pretty
easy. But again it was sixteen from

41
00:03:44,039 --> 00:03:47,479
seventeen. It was just one version
of date. But when would it really

42
00:03:47,560 --> 00:03:54,280
be a problem if we're like on
version ten twelve. Yeah, well,

43
00:03:54,479 --> 00:04:00,840
upgrading itself isn't Usually the problem.
Upgrading is the beginning of the problem.

44
00:04:01,599 --> 00:04:06,879
Like, you can upgrade to version
seventeen right now if you are not too

45
00:04:06,919 --> 00:04:12,800
far behind. But if you upgrade
to version seventeen, well you will have

46
00:04:12,919 --> 00:04:15,759
all the stuff that has been improved
under the hood, like better optimization,

47
00:04:15,920 --> 00:04:20,079
if you have SSR, like you
will have better support for SSR and so

48
00:04:20,160 --> 00:04:25,839
on, but you would still need
to change a bunch of code if you

49
00:04:25,920 --> 00:04:32,279
want to adopt the new approaches to
writing code. So if you use well,

50
00:04:32,439 --> 00:04:35,879
one thing we need to address is
that in Angular version sixteen, the

51
00:04:36,040 --> 00:04:42,439
Angular Compretibility Compiler, the NGCC,
has been removed, So upgrading from twelve

52
00:04:42,480 --> 00:04:47,759
to seventeen could be even like impossible. If you're using dependencies that are not

53
00:04:48,240 --> 00:04:55,360
supporting iv well, you shouldn't.
You shouldn't really use those libraries because if

54
00:04:55,519 --> 00:05:00,560
in version sixteen and seventeen they're not
supporting IVY and they are like such dependencies

55
00:05:00,600 --> 00:05:04,879
aren't properly maintained, so it would
be best to avoid. But if a

56
00:05:05,000 --> 00:05:11,040
project is already married to such a
dependency, yeah, you're going to have

57
00:05:11,040 --> 00:05:15,680
a real big problem upgrading to Angular
sixteen and beyond. Let's say you don't

58
00:05:15,680 --> 00:05:18,800
have that problem. Let's say it's
okay, you can upgrade to Angular seventeen

59
00:05:18,920 --> 00:05:24,279
from whatever version. There's a bunch
of stuff going on. If you didn't

60
00:05:24,279 --> 00:05:27,839
have standalone components, you would want
to have stand alone components, and that

61
00:05:28,199 --> 00:05:32,839
itself is like a very huge migration. You migrate your component code, you

62
00:05:32,920 --> 00:05:38,879
migrate your configurations. You migrate like
a bunch of stuff, and it entirely

63
00:05:38,920 --> 00:05:45,240
depends on how your project was built. So then you would want, for

64
00:05:45,279 --> 00:05:47,040
example, the image directive. If
there in images, you'll be like,

65
00:05:47,079 --> 00:05:49,920
oh, okay, sure, let's
use the engine optimized director. But that

66
00:05:50,040 --> 00:05:55,839
also involves a bunch of stuff.
You need to configure something, you need

67
00:05:55,920 --> 00:05:59,240
to import the directive, you need
to put the directive. By the way,

68
00:05:59,560 --> 00:06:02,759
the image directive has been backwarded to
version thirteen, so if you are

69
00:06:02,759 --> 00:06:06,399
on like twelve and you want it, you can go just to fourteen.

70
00:06:06,399 --> 00:06:11,600
You don't need to upgrade to like
version fifteen to get the image director.

71
00:06:12,360 --> 00:06:17,720
And then there is the new control
flow syntax. Well, it is not

72
00:06:18,000 --> 00:06:24,319
stable yet. I mean you could
skip that for now, but there are

73
00:06:24,360 --> 00:06:28,240
all the tools available to do the
transition right now, or even if you

74
00:06:28,839 --> 00:06:31,639
like, if you do that in
six months when it becomes stable eventually in

75
00:06:31,720 --> 00:06:39,519
version eighteen, this discussion that we
have now will still be relevant because maybe

76
00:06:39,560 --> 00:06:42,879
some syntax thing will change, but
the overall stuff will be the same,

77
00:06:42,920 --> 00:06:47,600
and the overall upgrade and migration process
will be the same, so it's not

78
00:06:47,680 --> 00:06:51,639
a version problem. But of course
the newer version you have the easier,

79
00:06:51,720 --> 00:06:56,120
at least the initial staffs will be
I mean, as you said, from

80
00:06:56,160 --> 00:07:01,560
sixteen to seventeen, upgrade like should
be payless. That makes sense. So

81
00:07:01,680 --> 00:07:04,000
I'm just going to jump in and
see if i can restate some of this.

82
00:07:04,160 --> 00:07:11,480
So as far as backward compatibility goes, you can upgrade it and it'll

83
00:07:11,560 --> 00:07:14,959
keep working. Right your your website's
not going to crash, it's not going

84
00:07:15,040 --> 00:07:17,160
to throw a bunch of ugly airs, it's not going to do anything you

85
00:07:17,160 --> 00:07:20,360
don't expect. What we're talking about
is, hey, there's a bunch of

86
00:07:20,360 --> 00:07:26,319
great stuff in the newer versions that
you probably want to take advantage of to

87
00:07:26,399 --> 00:07:30,639
make your development faster, to make
your app runs more smoothly, to you

88
00:07:30,639 --> 00:07:34,360
know, to get better performance and
things like that. Absolutely, yeah,

89
00:07:34,439 --> 00:07:40,399
yeah, that's the case. So
so you talked a little bit about some

90
00:07:40,439 --> 00:07:42,680
of these things. It's like,
well, you may want to upgrade,

91
00:07:42,720 --> 00:07:46,959
like you said, you may want
standalone components. So so what does that

92
00:07:46,000 --> 00:07:50,240
process look like? Because I've I
kind of dabble an angular and so I

93
00:07:50,279 --> 00:07:56,399
don't actually know what that process looks
like. Right. I may have written

94
00:07:56,399 --> 00:08:00,680
some standalone components at some point.
I may have written some old their components

95
00:08:00,680 --> 00:08:03,439
at some point, and I've never
had a push from one to the other.

96
00:08:05,879 --> 00:08:09,199
Yeah, so standalone, Yeah,
that's a good place to start because

97
00:08:09,920 --> 00:08:15,399
it's an older change. We got
standalone in version fourteen and in version fifteen

98
00:08:15,480 --> 00:08:20,879
it is stable, so we had
a lot of time to try to upgrade.

99
00:08:20,959 --> 00:08:24,879
So the great thing about standalone is
that fully interoperates with modules. So

100
00:08:26,319 --> 00:08:33,879
what one can do is sort of
do the migration iteratively, okay, like

101
00:08:33,000 --> 00:08:37,639
incremental steps. You do one component, then you do another component. You

102
00:08:37,840 --> 00:08:41,960
remove one engine module, then you
remove another. Then at the end of

103
00:08:41,960 --> 00:08:46,720
the day, just remove the root
module. You configure using the functional API

104
00:08:46,879 --> 00:08:50,279
is the new APIs, and then
you are done. Of course that's a

105
00:08:50,320 --> 00:08:54,360
manual approach, okay, which is
reasonable, especially if you have like a

106
00:08:54,440 --> 00:08:58,840
huge project. Then yeah, maybe
you can change one thing another thing,

107
00:08:58,960 --> 00:09:03,000
change the tests, and in the
end they be sure that nothing broke.

108
00:09:03,200 --> 00:09:07,879
Okay, but yeah, that takes
a lot of time. For a project

109
00:09:07,879 --> 00:09:15,440
that is like less risky. You
can easily use the schematic that the Angular

110
00:09:15,440 --> 00:09:18,799
team provides. So they give you
this schematic which goes as far as I

111
00:09:18,879 --> 00:09:24,360
remember, it was like engine generates
at angular slash standalone something like that.

112
00:09:26,480 --> 00:09:30,559
Well, the exact amount is irrelevant, but you have this command that you

113
00:09:30,600 --> 00:09:35,080
can run on your project inside your
say project route, and then full scam

114
00:09:35,159 --> 00:09:41,639
through your files and find engine modules
and fund components and make components stand alone.

115
00:09:41,440 --> 00:09:46,440
And the beautiful thing about the schematic
is that it actually works in free

116
00:09:46,440 --> 00:09:50,120
steps, so you have to run
it three times. First time, it

117
00:09:50,200 --> 00:09:56,039
will mark your components as stand alone. So what it will do it will

118
00:09:56,080 --> 00:10:03,000
go find all the component the creators
and put standalone through there. And because

119
00:10:03,000 --> 00:10:05,679
the component is now stand alone,
it cannot be declared in an engine module,

120
00:10:05,679 --> 00:10:09,639
but it can be imported into an
engine module. And then it will

121
00:10:09,679 --> 00:10:15,159
go to the engine model where it
is declared and just remove the declaration and

122
00:10:15,200 --> 00:10:20,480
put it inside the import statement.
Okay, okay, And that way you

123
00:10:22,639 --> 00:10:26,000
get the situation that, ah sure, now this component is using. It

124
00:10:28,039 --> 00:10:31,720
imports the stuff itself, so it
will add the inforce that this component is

125
00:10:31,799 --> 00:10:35,600
using from the engine model and it
will turn it into stand alone. So

126
00:10:35,639 --> 00:10:39,799
now you have a bunch of standalone
components, but your application architecture is engine

127
00:10:39,840 --> 00:10:46,600
model based. Okay. The second
time you run the command it will actually

128
00:10:46,639 --> 00:10:52,080
go around and update the imports for
those components that are now stand alone,

129
00:10:52,399 --> 00:10:56,639
so now they only fully import not
the module, but they import like other

130
00:10:56,799 --> 00:11:03,720
standalone components from our project. And
finally, you can run the command the

131
00:11:03,799 --> 00:11:07,200
third time and will just because after
these two commands, your engine modules are

132
00:11:07,279 --> 00:11:13,320
essentially obsolete. You don't really need
them because everything is declared around standalone.

133
00:11:13,440 --> 00:11:16,519
And then you can just run the
command the first time and will remove the

134
00:11:16,840 --> 00:11:22,120
engine modules that are now useless okay, and will create the maints file and

135
00:11:22,159 --> 00:11:26,000
the app convict tis file that we
have now with new Angular projects, put

136
00:11:26,039 --> 00:11:30,320
the dependencies there and so on.
And yeah, you can put a flag

137
00:11:30,360 --> 00:11:35,159
that will start using the standalone APIs. For example, if you're using router

138
00:11:35,320 --> 00:11:37,759
module, it will remove it and
put the provide router and so on.

139
00:11:39,960 --> 00:11:43,559
It's not ideal, it's not ideal
because sometimes it will miss something, especially

140
00:11:43,600 --> 00:11:48,200
if you have like circular dependencies and
so on. I will mention about that.

141
00:11:48,519 --> 00:11:52,200
Also a good thing if you have
a large project, you can actually

142
00:11:52,320 --> 00:11:58,840
run this command in a subdirector,
so instead of instantly moving your entire up,

143
00:11:58,919 --> 00:12:01,559
you can for example, if you
have a module based architecture, you

144
00:12:01,600 --> 00:12:05,200
can pick one feature module I don't
know, user's module. Okay, let's

145
00:12:05,240 --> 00:12:09,200
convert this to standalone. Converted round
the tests I don't know, check it

146
00:12:09,240 --> 00:12:13,519
manually. If you think everything is
good, you can move to another module,

147
00:12:13,519 --> 00:12:16,440
and then so on and so on
until you left with just root module,

148
00:12:16,440 --> 00:12:24,799
which you can even move just manually. And there are also modules that

149
00:12:24,519 --> 00:12:31,080
for example, they use for root
and they dynamically provide something and not for

150
00:12:31,120 --> 00:12:37,200
example, not every third party library
that uses that structure has been fully migrated

151
00:12:37,240 --> 00:12:41,200
to stand alone. So one option
is to also use import providers from.

152
00:12:41,559 --> 00:12:46,639
That was actually really important for the
migration of many of the projects that we

153
00:12:46,720 --> 00:12:52,559
had. So if you're using dynamic
providers, I think that actually also works

154
00:12:52,559 --> 00:12:56,679
with regular modules, right armen,
Like if you just want to yeah,

155
00:12:56,720 --> 00:13:03,000
so if you just want to migrate, like you don't want to really get

156
00:13:03,080 --> 00:13:05,159
rid of the engine modules right now, but you want to at least migrate

157
00:13:05,200 --> 00:13:13,879
the bootstrap file to use the new
standalone bootstrap and to use the application can

158
00:13:13,919 --> 00:13:20,720
figure isolated from the rest. You
can do that by using this function called

159
00:13:20,759 --> 00:13:24,919
import provisors from. So this function
is important from Angular Core and it allows

160
00:13:24,960 --> 00:13:28,879
you to pass all the modules as
arguments to it, and then it's just

161
00:13:28,919 --> 00:13:35,600
going to provide them as you were
already doing with your regular app module in

162
00:13:35,639 --> 00:13:39,759
the past. That's a really good
catch. I actually kind of forgot about

163
00:13:39,759 --> 00:13:45,720
the providers from function. Engine models
are not gone, they're not deprecated.

164
00:13:45,960 --> 00:13:52,360
There are no official plans on deprecating. I mean maybe eventually, we don't

165
00:13:52,399 --> 00:13:54,480
know, but right now it's not
on the road map. So the Angular

166
00:13:54,519 --> 00:13:58,720
team is creed that Engie models are
here. If you want to use standalone,

167
00:13:58,039 --> 00:14:01,879
no problem. Inside Angular there's a
bunch of stuff that is still engine

168
00:14:01,879 --> 00:14:07,960
model based, form controls forms module, reactive forms module, they're still there.

169
00:14:09,000 --> 00:14:11,759
You have to import the modules to
be able to use by the way

170
00:14:11,759 --> 00:14:16,240
I actually investigate it. And you
know what's the reason behind that. Like

171
00:14:16,360 --> 00:14:20,639
all the other stuff is stand alone
now, right, you have Engie class,

172
00:14:20,840 --> 00:14:24,320
engine switch blah blah blah. All
that is stand alone. But the

173
00:14:26,759 --> 00:14:31,159
you know, the engine module,
sorry, the engine model, form control

174
00:14:31,200 --> 00:14:35,799
and so on directives, they are
not stand alone. And the thing is

175
00:14:35,840 --> 00:14:39,679
that actually, like when you put
engine model or you know, there's a

176
00:14:39,720 --> 00:14:45,879
directive called engine model, right,
but actually it's not just one directive.

177
00:14:46,200 --> 00:14:52,399
It's actually a family of directives because
engine model model for a radio button is

178
00:14:52,399 --> 00:14:58,600
completely different from an engine model for
let's say I don't know select HTML element

179
00:14:58,799 --> 00:15:03,360
or usual input. So actually,
under the hood they are multiple engine model

180
00:15:03,399 --> 00:15:07,720
directives. One match is already about
one matches for inputs and so on,

181
00:15:09,120 --> 00:15:13,000
and if you want to use them, you need to import the entire thing,

182
00:15:13,039 --> 00:15:18,480
so you are able to put engine
model on whatever native HTML form elements

183
00:15:18,639 --> 00:15:24,320
you want. That's why, for
now and for the foreseeable future, dozen

184
00:15:24,360 --> 00:15:28,679
engine modules will place there. I
mean, I would bet that in the

185
00:15:28,759 --> 00:15:33,799
future, engine models will be sort
of marketed, not as like application backbone

186
00:15:35,679 --> 00:15:41,399
or a way to create architecture,
but rather a way to group related components,

187
00:15:41,519 --> 00:15:46,919
maybe even standalone components, so that
if you know that these things are

188
00:15:46,919 --> 00:15:50,600
always used in conjunction, okay,
you can group them in a module and

189
00:15:50,720 --> 00:15:54,519
maybe import them altogether. I'm not
sure about it. It's just speculation,

190
00:15:54,799 --> 00:15:58,519
but you know, the way this
is going, it is one possibility.

191
00:16:00,600 --> 00:16:03,519
I think that that makes a ton
of sense, like doing the standalone migration

192
00:16:03,639 --> 00:16:08,279
first, and you're right, Like, the only reason why I haven't felt

193
00:16:08,840 --> 00:16:15,600
that much of the pain to migrate
was because I was already I had already

194
00:16:15,639 --> 00:16:19,120
migrated those things before, so you're
right. And one thing that didn't worked

195
00:16:19,120 --> 00:16:27,480
out super well to me though,
was the new control flow syntax and running

196
00:16:27,519 --> 00:16:34,639
the migration on NX like it just
it wasn't so straightforward to run the migration

197
00:16:36,879 --> 00:16:44,600
using NX because I had to like
the regular Engie command wouldn't work, so

198
00:16:44,639 --> 00:16:48,919
I would have to use it through
NX and pass some other parameters to it.

199
00:16:49,039 --> 00:16:56,639
And then there was also like a
two particular components that weren't properly migrated,

200
00:16:57,159 --> 00:17:03,559
Like yes they were at first,
but if I rented again it would

201
00:17:06,000 --> 00:17:11,480
it would actually generate some issues because
like I had stuff inside my engine switch,

202
00:17:12,519 --> 00:17:17,680
and I can't have things inside Angie
switch anymore. You can only have

203
00:17:17,720 --> 00:17:22,839
things inside inside switch cases and the
default case, but you can't just have

204
00:17:22,920 --> 00:17:30,160
things lying around inside the switch block. So that was actually a problem that

205
00:17:30,200 --> 00:17:33,240
I had with the migration. But
other than that, which was something that

206
00:17:33,359 --> 00:17:41,039
I was able to migrate manually,
everything else was pretty straightforward. That's actually

207
00:17:41,039 --> 00:17:45,960
an interesting point I thought about it, the having some content other than cases.

208
00:17:48,200 --> 00:17:56,480
Although I have tried out the schematic
on a let's say, usual project,

209
00:17:56,559 --> 00:18:03,920
not with an X, it worked
wonderfully for me. Actually it worked

210
00:18:03,920 --> 00:18:07,480
only on the templates, which kind
of makes sense because you know, if

211
00:18:07,480 --> 00:18:14,240
you remove the imports that might possibly
break something. But actually someone on Twitter

212
00:18:14,319 --> 00:18:18,240
corrected me that there's actually flag that
you can put and the command will also

213
00:18:18,400 --> 00:18:23,519
just remove the imports for NGS switch
and so on. What was interesting for

214
00:18:23,599 --> 00:18:29,240
me, like one important point is
that with the new syntax, the track

215
00:18:29,680 --> 00:18:33,920
modifier is required for for loops.
Right, so with the Engie four you

216
00:18:33,960 --> 00:18:37,440
could skip like the track by function. You shouldn't, but most of the

217
00:18:37,480 --> 00:18:42,839
people skip that anyway. With the
new syntax, it requires that you put

218
00:18:42,839 --> 00:18:47,279
the tracker, like in React when
it requires to put the key when we're

219
00:18:47,319 --> 00:18:52,039
mapping over an array, and the
same now is true for Angular, which

220
00:18:52,079 --> 00:18:57,359
is a good development. I welcome
it, but it's a bit tricky with

221
00:18:57,400 --> 00:19:03,720
the migration because when you do the
migration, obviously lots of cases you will

222
00:19:03,799 --> 00:19:07,319
not have a track by function,
and what it will do it will put

223
00:19:07,519 --> 00:19:11,960
like if you have let's say eng
four lead item of items, it will

224
00:19:12,039 --> 00:19:19,880
change it to four items of items
and then track items. So essentially it's

225
00:19:19,920 --> 00:19:26,279
just a USEFULS modifier because it only
it tracks the exact reference to the object,

226
00:19:26,519 --> 00:19:33,079
which could obviously change without meaning a
change that must result in re render,

227
00:19:33,200 --> 00:19:36,359
right, and that is okay in
the sense that nothing will break.

228
00:19:36,400 --> 00:19:40,960
Actually your app will continue working as
usual. But you should probably jump on

229
00:19:41,000 --> 00:19:45,920
the opportunity and provide something more meaningful
to the track modifier, like maybe ide

230
00:19:45,160 --> 00:19:51,519
or whatever you are using to differentiate
between objects in a collection. Right,

231
00:19:52,000 --> 00:19:57,400
Yeah, that's that's one point.
And another point is that the switch switch

232
00:19:57,480 --> 00:20:04,240
case syntax. Now the switch each
case matching happens on strict equality. Okay,

233
00:20:06,519 --> 00:20:11,559
actually engine switch works with loose equality. I don't know why. I'm

234
00:20:11,599 --> 00:20:17,240
not sure, and I believe you
could modify that with some injection token,

235
00:20:17,480 --> 00:20:22,680
but that's like really obscure knowledge at
this point. So if you change,

236
00:20:22,680 --> 00:20:30,359
there is a small possibility if your
code relied on loose equality for matching cases,

237
00:20:30,200 --> 00:20:33,720
which again it shouldn't have probably,
but you have such a case,

238
00:20:34,039 --> 00:20:37,599
it's gonna be it probably will introduce
a bug into your switch case. So

239
00:20:37,640 --> 00:20:45,279
I would suggest I mean migrating if
statements the engine. If directed, that's

240
00:20:45,319 --> 00:20:52,480
just a piece of cake, like
no problem. But with switch and four

241
00:20:52,720 --> 00:20:56,599
loops you should probably be a bit
more careful. But in general, it's

242
00:20:56,640 --> 00:21:00,720
more of a mechanical thing. It's
easier to do than a stund long migration.

243
00:21:00,920 --> 00:21:04,440
I think ASTANDLE involves a bunch of
interconnected stuff, and you know four

244
00:21:04,519 --> 00:21:08,799
loop is a four loop, it's
in one place. Actually, I noticed

245
00:21:08,839 --> 00:21:14,720
that I tested it with different tricks
to see how it would work the migration.

246
00:21:14,839 --> 00:21:17,880
And actually, if you, for
example, put an ANGI IF statement

247
00:21:17,960 --> 00:21:21,799
on an engine container, the engine
container is not like an element itself,

248
00:21:21,880 --> 00:21:25,599
right, It's just a placeholder where
you could put like, for example,

249
00:21:26,079 --> 00:21:30,839
engine right. Uh, it will
actually just remove the ang container. It

250
00:21:30,920 --> 00:21:37,799
will just wrap the elements inside,
wrap in the if statement and be done

251
00:21:37,839 --> 00:21:41,440
with it. And that's really cool
because with the ang if you you always

252
00:21:41,440 --> 00:21:47,200
needed either a one current elements that
will also everything inside, or you were

253
00:21:47,240 --> 00:21:51,839
forced to use engine containers. Now
you can just write an if statement and

254
00:21:51,880 --> 00:21:55,240
the schemetic does that. It will
remove engine container and put the IF in

255
00:21:55,319 --> 00:22:03,599
itstead, so that that's really cool. I think I agree like just having

256
00:22:03,759 --> 00:22:10,559
those automated migrations makes our lives so
much easier, and it also makes it

257
00:22:10,640 --> 00:22:15,960
so much easier to defend angler because
there's always a friend that is gonna say,

258
00:22:15,400 --> 00:22:18,039
oh, you're using Angler, they
release a new version. Ha,

259
00:22:18,519 --> 00:22:33,880
Like, you're gonna have a bad
time because in the very reacts. So

260
00:22:34,079 --> 00:22:37,480
now we can just say yeah,
man, like we don't really have that

261
00:22:37,599 --> 00:22:42,559
problem anymore. They're not gonna believe
us anyways, because most of them don't

262
00:22:42,559 --> 00:22:48,319
even try it. But but we
know that we actually have a good excuse

263
00:22:48,400 --> 00:22:52,799
to tell them, Hey, no, actually it's much easier to upgrade nowadays.

264
00:22:53,000 --> 00:23:00,319
Yeah, I would say it's totally
worth it. I imagine how many

265
00:23:00,440 --> 00:23:06,640
new projects start with Angular and you
have already all of these awesome features.

266
00:23:07,119 --> 00:23:10,599
Oh, we're gonna do signals next? How to migrate to signals because there's

267
00:23:10,680 --> 00:23:15,440
no schematic for that. That is
a very good point, and I don't

268
00:23:15,480 --> 00:23:18,319
think we're gonna have right just to
make it clear to the audience, like

269
00:23:18,359 --> 00:23:25,160
it's not something that is being done
and you just have to wait. Oh,

270
00:23:25,160 --> 00:23:30,000
I don't think it's something that is
even like theoretically possible, because how

271
00:23:30,000 --> 00:23:32,920
would you figure out if something needs
to be a signal or not? I

272
00:23:32,920 --> 00:23:38,400
mean one approach would be to go
through the template, see what stuff is

273
00:23:38,839 --> 00:23:45,599
a signal, is a binding and
just like convert those properties to signals,

274
00:23:45,920 --> 00:23:52,440
which I guess I mean, it
could be done, but it could be

275
00:23:52,480 --> 00:23:56,680
problematic too. Like if it's a
bulliant property, okay, we can do

276
00:23:56,759 --> 00:24:02,200
that easily. We could go and
say, okay, whenever we say,

277
00:24:02,400 --> 00:24:06,319
let's say you have loading property which
is a bullion. Now you want to

278
00:24:06,359 --> 00:24:08,920
turn it signal, Well, no
problem. You just instead of saying like

279
00:24:10,039 --> 00:24:15,759
loading equals true, you could say
loading equals signal true. And whenever you

280
00:24:15,920 --> 00:24:19,400
assign something to the loading property,
you say loading equals false for example.

281
00:24:19,839 --> 00:24:23,839
Instead of that, you could just
do loading dot set true. Okay,

282
00:24:23,839 --> 00:24:32,319
that's a simple case. But okay, how about an array. You can

283
00:24:32,440 --> 00:24:34,200
have an array of a signal a
signal of an array. I mean,

284
00:24:34,319 --> 00:24:37,559
that's a perfectly reasonable use case.
And now you have a bunch of let's

285
00:24:37,599 --> 00:24:41,519
say array dot push statements. How
do you go on about converting that?

286
00:24:42,920 --> 00:24:48,240
Do you use the I mean,
that's a bunch of stuff that you need

287
00:24:48,319 --> 00:24:52,839
to consider, and I'm not really
sure you could like deterministically convert all of

288
00:24:52,880 --> 00:24:59,799
them. It's gonna involve manual labor, Okay, and again you don't probably

289
00:25:00,039 --> 00:25:06,039
you don't need all of your properties
to be signals, so it really depends.

290
00:25:06,680 --> 00:25:12,240
But there are manual approaches that you
can adopt. That would probably result

291
00:25:12,279 --> 00:25:15,920
in a pretty smooth transition, because
again, signals, they're just you know,

292
00:25:15,960 --> 00:25:18,359
reactive freematives. You can use them, you cannot use them. You

293
00:25:18,400 --> 00:25:22,759
can use both signals and like usual
properties, so you can just do it.

294
00:25:22,839 --> 00:25:26,160
Let's say, you know, I
noticed that I use this word a

295
00:25:26,200 --> 00:25:33,200
lot in the last year incrementally one
amazing place to start. If you have

296
00:25:33,279 --> 00:25:37,920
behavior subjects in your angular code,
you know, you just don't ditch them

297
00:25:38,079 --> 00:25:44,079
and use a signal because essentially a
behavior subject and the signal are the same

298
00:25:44,119 --> 00:25:48,519
thing. At the end of the
day. Of course, behavior subject you

299
00:25:48,519 --> 00:25:53,480
could pipe and add operators to it, but in most cases you're using something

300
00:25:53,559 --> 00:25:59,359
like map or tap, so either
a side effect or you know, transformation

301
00:25:59,640 --> 00:26:04,480
into another observable. So well,
for the first one you can use an

302
00:26:04,480 --> 00:26:10,079
effect. For side effects also you
just you can just take the same collback,

303
00:26:10,119 --> 00:26:12,240
put it into an effect statement and
be done with it. And for

304
00:26:12,440 --> 00:26:18,160
maps you can use you know,
computer properties. So conversion of a behavior

305
00:26:18,160 --> 00:26:22,240
subject to signal in ninety five percent
of the case is going to be very

306
00:26:22,240 --> 00:26:26,119
smooth. Okay, So yeah,
you could just hunt for behavior subjects in

307
00:26:26,160 --> 00:26:32,680
your code and just turn them into
signals. If you have ordinary subjects or

308
00:26:32,680 --> 00:26:36,440
observable as well, no problem.
Wrap them in a two signal like use

309
00:26:36,720 --> 00:26:40,200
RXG, just interrop convert them to
signal. Now your templates are not using

310
00:26:40,240 --> 00:26:45,039
the acing pipe. It's an overall
improvement. And again you can go on

311
00:26:45,119 --> 00:26:48,279
about like the simple properties that are
reactive. Again, if you have like

312
00:26:48,319 --> 00:26:53,440
a loading Bullian property, it's fairly
easy to manually convert into signal. Not

313
00:26:53,519 --> 00:26:59,960
a big deal at all, will
not break anything. Just keep in mind

314
00:27:00,640 --> 00:27:03,960
that you know you've got to have
problems with objects. So you can start

315
00:27:04,000 --> 00:27:11,480
with primitive properties, extreme Bullians on
and then the final part you can move

316
00:27:11,519 --> 00:27:18,440
on to modifying race making them into
signals of a race. So yeah,

317
00:27:18,599 --> 00:27:22,640
that's the am project I would adopt, because there's never gonna be a schematic

318
00:27:22,640 --> 00:27:26,720
for me. I don't think so, Carman, How do you feel about

319
00:27:27,519 --> 00:27:36,799
signals versus behavior subjects in context where
where it's not just a component. For

320
00:27:36,880 --> 00:27:41,680
example, I have some utilities that
I reuse in many of my projects,

321
00:27:42,119 --> 00:27:48,640
and a lot of them rely heavily
on our XS to do some to do

322
00:27:48,680 --> 00:27:55,400
some logic, For example, I
have something that does I'm trying to remember

323
00:27:55,440 --> 00:27:59,000
the name that I gave to it. I think it's like thrashold controllers something

324
00:27:59,079 --> 00:28:03,039
like that. It's a It's a
utility that I created so that I could

325
00:28:03,160 --> 00:28:07,640
run a bunch of jobs in parallel, but also make sure that I could

326
00:28:07,680 --> 00:28:11,160
limit the amount that was running at
the same time. So it's basically a

327
00:28:11,279 --> 00:28:15,519
queue, but it allows jobs to
be parallelized up to a certain amount.

328
00:28:15,920 --> 00:28:22,160
Right, So I built that,
and I used rxgs and behavior subjects to

329
00:28:22,880 --> 00:28:27,559
listen to the changes in how many
jobs are active and how many jobs are

330
00:28:27,599 --> 00:28:32,279
completed, etc. So, as
you can see, it's not a very

331
00:28:32,359 --> 00:28:37,759
angular specific thing. It's a piece
of code that I can even reuse in

332
00:28:37,759 --> 00:28:42,359
a back end environment, in an
environment that has nothing to do with angular

333
00:28:42,400 --> 00:28:52,559
whatsoever. But I was wondering if
for such scenarios there would be something simpler

334
00:28:52,599 --> 00:28:57,359
than a behavior subject. But I
also understand that I can't use a signal

335
00:28:57,519 --> 00:29:03,119
because I wanted to work other environments. So what I'm actually asking is,

336
00:29:03,119 --> 00:29:07,799
is there like a non angular specific
version of a signal that I can use

337
00:29:07,920 --> 00:29:17,880
in such cases? Well, you
mentioned parallelizing tasks, so it's gonna be

338
00:29:17,920 --> 00:29:25,079
asynchronous, right, good, So
there is no version of signals in existence

339
00:29:25,160 --> 00:29:29,039
right now that could do that.
The whole stick of the signals is that

340
00:29:29,079 --> 00:29:36,359
they're synchronous. They almost completely synchronous. Computed properties and proper signals they are

341
00:29:36,480 --> 00:29:42,880
synchronous, and effects they are asynchronous
kind of like in reality. Yeah,

342
00:29:42,880 --> 00:29:47,599
they are asynchronous, though they work
in in the different fashion that you would

343
00:29:47,599 --> 00:29:52,400
expect. So essentially almost all the
stuff that revolves around signals is asynchronous.

344
00:29:52,200 --> 00:29:56,079
My go to approach is to see
if the logic that I'm trying to incorporate,

345
00:29:56,240 --> 00:30:00,119
like when we say reactive, often
people think that that that's a synchronous,

346
00:30:00,160 --> 00:30:03,799
but that that's not really the case. You could have reactive code that

347
00:30:03,880 --> 00:30:08,279
synchronous. Reactive is essentially just notifying
somewhere that something happened. You can do

348
00:30:08,319 --> 00:30:12,599
that synchronous, right, you will
you have an array of callbacks and you

349
00:30:12,720 --> 00:30:18,839
just call one of the callbacks and
now all the consumers are notified. But

350
00:30:19,200 --> 00:30:23,960
there hasn't been an a sync tick. Right, So, if if I

351
00:30:23,960 --> 00:30:30,640
have something that is reactive, I
would just use signals reactive but not asynchronous.

352
00:30:30,839 --> 00:30:34,720
If I have something like a stream
of events, then then I'm gonna

353
00:30:34,720 --> 00:30:41,359
have asynchronicity, right, acinc code
then I'm gonna use RHS because I cannot

354
00:30:41,400 --> 00:30:48,000
possibly use signals for that because signals
are synchronous. How am I, for

355
00:30:48,039 --> 00:30:52,960
example, how I'm gonna check that
there are let's say, these many parallel

356
00:30:53,039 --> 00:30:59,640
tasks going on. If the update
to one test triggers all the you know,

357
00:30:59,680 --> 00:31:02,799
computer, the properties and so not, that won't be really feasible.

358
00:31:02,839 --> 00:31:07,599
And it should not because signals are
reactive states and RGS is now reserved for

359
00:31:07,720 --> 00:31:11,400
asynchronous event. So you have streams
of events, not state, and you

360
00:31:11,480 --> 00:31:18,079
have reactive state not events. That's
that's that's the whole let's say upgrade for

361
00:31:18,200 --> 00:31:25,359
us. And actually there is another
like angular problem with that, like what

362
00:31:25,519 --> 00:31:29,319
people will do. They would say, okay, let's use RHS, for

363
00:31:29,359 --> 00:31:33,519
example in services for all the stuff
going on like event pas, whatever.

364
00:31:34,079 --> 00:31:37,000
And then we'll say, but okay, in the component, I want to

365
00:31:37,119 --> 00:31:41,000
use the signal version of this.
I want to derive some state from these

366
00:31:41,119 --> 00:31:45,119
events and use it as a signal
in a component, which is completely well

367
00:31:45,200 --> 00:31:48,720
the use case. And what they
will do they will like call to signal

368
00:31:48,759 --> 00:31:53,599
in the service. Now you've got
yourself a problem because to signal immediately subscribes

369
00:31:53,640 --> 00:32:00,119
to the observable, and maybe that
observable just waits to be subscribed, so

370
00:32:00,200 --> 00:32:04,000
it doesn't work. It's a cold
observable. Now you subscribe to it,

371
00:32:04,079 --> 00:32:08,200
so it's now a hot observable.
More So, even if the component where

372
00:32:08,240 --> 00:32:14,920
you are using it gets destroyed,
well bad luck. You called to signal

373
00:32:14,960 --> 00:32:19,000
in the service. And if the
service is provided in the root injector,

374
00:32:19,559 --> 00:32:23,200
well it's gonna leave. That subscription
is gonna leave until the end of the

375
00:32:23,319 --> 00:32:28,279
entire application. So what you need
to do is either just used to signal

376
00:32:28,279 --> 00:32:34,119
function in the in the component,
or if you want more like even more

377
00:32:34,119 --> 00:32:39,000
granular control, you probably should,
I don't know, add some method on

378
00:32:39,039 --> 00:32:43,599
your service that like that's a real
approach that people are using. Now you

379
00:32:43,640 --> 00:32:46,799
call it the connect method, and
you call connect method whenever you need it

380
00:32:46,799 --> 00:32:51,680
in the component. Like you have
something in the service, you say connect

381
00:32:52,000 --> 00:32:55,400
and now all the signals are connected
to the observable. Only after that it

382
00:32:55,480 --> 00:32:59,759
will begin to work and then it
will be destroyed. In engine destroy you

383
00:32:59,799 --> 00:33:07,880
get at the logic inside that specific
function. Okay, you cannot do acing

384
00:33:07,880 --> 00:33:14,920
stuff with signals like bottom line.
Yeah, that's a that's a very good

385
00:33:14,920 --> 00:33:20,960
point. You're right, my question
entirelie didn't make didn't make sense after I

386
00:33:21,039 --> 00:33:24,920
did, it did because I mean, it's perfectly natural, especially if you

387
00:33:24,960 --> 00:33:29,880
when you when you talk about like
your example was really good because you're talking

388
00:33:29,880 --> 00:33:32,920
about a set of things that are
working asynchronous, so you have essentially a

389
00:33:32,960 --> 00:33:39,000
state. It's not even a question
about what events those other let's say tasks

390
00:33:39,680 --> 00:33:44,400
would emit at some point. It's
a question of how you can keep track

391
00:33:44,440 --> 00:33:47,359
of them and so on. You
could do that part with signals, but

392
00:33:49,400 --> 00:33:53,720
the very moment you connect to the
actual streams, you can no longer really

393
00:33:53,839 --> 00:33:58,400
use signals for that. That's the
problem. You could use it for a

394
00:33:58,440 --> 00:34:01,359
state if you have reactive state,
did you have a list of events?

395
00:34:01,880 --> 00:34:07,519
Well, but luck, I mean
you could derive like today, I did

396
00:34:07,880 --> 00:34:15,119
a small thing for upcoming training of
mine. So it's a clock. Okay,

397
00:34:15,119 --> 00:34:17,400
it's a clock that displays the current
time, and I want to do

398
00:34:17,440 --> 00:34:22,039
that with the signal. So what
I do I use urgually as interval mapped

399
00:34:22,119 --> 00:34:25,559
to the current date. Okay,
then used two signal. Now I have

400
00:34:25,599 --> 00:34:30,960
a signal of the current date,
which constantly every second it gets updated.

401
00:34:30,239 --> 00:34:35,840
But it's a stage. Now it's
a date that changed depending on I don't

402
00:34:35,840 --> 00:34:42,119
know whatever doesn't matter. Maybe I'm
getting the current day time via a website

403
00:34:42,440 --> 00:34:47,480
from a or whatever. For that
reason. Now I have a signal.

404
00:34:47,519 --> 00:34:51,679
Now I can just do a computing
property, and now I have myself beautiful

405
00:34:51,719 --> 00:34:55,960
formative time that I can display in
the HTML. We should realize that the

406
00:34:57,000 --> 00:35:00,199
main point of signals, outside of
you know, cold and so on,

407
00:35:00,840 --> 00:35:07,519
is to aid we change detection is
to be as granular as possible and as

408
00:35:07,559 --> 00:35:10,719
simple to like they could do it
with dark just two because R is also

409
00:35:10,760 --> 00:35:15,880
not fastible changes. Right, gave
a subject, as we mentioned, but

410
00:35:15,960 --> 00:35:19,119
they wanted something really simple, and
you can just drop the signal of this.

411
00:35:19,280 --> 00:35:22,639
Okay, set value, read value. Okay, I'm done, because

412
00:35:22,719 --> 00:35:29,320
under the hood it does call I
don't know, marked component dirty. You

413
00:35:29,400 --> 00:35:36,000
might have seen in Angerer seventeen they
have like really silently introduced this thing called

414
00:35:36,119 --> 00:35:40,159
local change detection. So, if
you're not familiar with signals, if your

415
00:35:40,239 --> 00:35:45,039
component and all these ancestors are on
push, which is often the case with

416
00:35:45,119 --> 00:35:50,199
lots of projects, like people like
to mark their components on push, now

417
00:35:50,679 --> 00:35:55,000
in that component, if a signal
is changed, only that component is change

418
00:35:55,000 --> 00:36:00,000
detected. No, not No parents
are marked as dirty if they are also

419
00:36:00,079 --> 00:36:06,000
on Push, which is actually a
very very significant development because up until this

420
00:36:06,079 --> 00:36:12,000
point, your best case optimization was
to run change detection only on components ancestor

421
00:36:12,199 --> 00:36:15,559
instead of all of the components in
the project. Now you can just say,

422
00:36:15,559 --> 00:36:20,159
okay, change to take this one
component and you don't have to do

423
00:36:20,280 --> 00:36:23,599
much, just use signals and push
change detection strategy on Push. Yeah,

424
00:36:24,760 --> 00:36:30,559
that's the main reason for signals.
Signals are magic. They're really cool.

425
00:36:34,039 --> 00:36:37,960
They are they are. They still
have problems that they need to work out,

426
00:36:37,079 --> 00:36:42,440
but well, the API is stables, so we're okay using them other

427
00:36:42,480 --> 00:36:45,440
than effect is not stable yet.
But you know, you shouldn't probably use

428
00:36:45,480 --> 00:36:51,559
effects that much anyway, like ninety
nine percent scenarios, you don't really need

429
00:36:51,599 --> 00:37:00,320
an effect. Yep. Okay.
Do you think there's any other major saying

430
00:37:00,360 --> 00:37:05,559
that we should cover on the subject
of today's episode in terms of migrations to

431
00:37:05,639 --> 00:37:08,639
the lads? So yeah, one
last thing, Yeah, one last thing

432
00:37:09,119 --> 00:37:15,679
that is of course SSR. Now, well, I think we did the

433
00:37:15,760 --> 00:37:20,960
last episode on SSR in general,
and we mentioned that SSR now its own

434
00:37:21,000 --> 00:37:24,559
package inside Angular, so you don't
have like Angler universe or support, and

435
00:37:24,639 --> 00:37:30,119
now you just have angular slash SSRU. And the cool thing about it is

436
00:37:30,159 --> 00:37:32,880
also supposed that the anged schematic.
So if you have a project that is

437
00:37:34,000 --> 00:37:39,199
not a SSR, you can add
a SSR using the NGAD angular slash as

438
00:37:39,199 --> 00:37:44,639
a SR command and we'll do a
bunch of stuff to generate a server ts

439
00:37:44,679 --> 00:37:51,039
file a if I remember correctly,
a main dot server ts file. Those

440
00:37:51,039 --> 00:37:52,920
are actually different. You have one
server ts file which has the like a

441
00:37:52,960 --> 00:37:57,519
no GS server conflict, and you
have a main server ts file that is

442
00:37:57,559 --> 00:38:02,039
an angular conflict for the and it
will add all all the stuff that you

443
00:38:02,079 --> 00:38:06,199
need to a clan side, the
hydration and so on and so on.

444
00:38:07,119 --> 00:38:10,000
So in general, it's a simple
schematic. So it's it's probably the easiest

445
00:38:10,039 --> 00:38:14,039
outside of the things that we're talking
about, because as a starry itself,

446
00:38:15,239 --> 00:38:21,280
the schematic migration is pretty straightforward.
You don't change the actual code. I

447
00:38:21,320 --> 00:38:24,440
will talk about it now. You
don't need to change the actual code in

448
00:38:24,519 --> 00:38:29,920
nineteen nine percent of scenarios, So
yeah, it makes sense to run a

449
00:38:29,920 --> 00:38:34,599
schematic. Then you're gonna have some
bugs, and those bugs you will have

450
00:38:35,079 --> 00:38:39,199
only in the scenario where you are
actually updating the dome using like the browser

451
00:38:39,239 --> 00:38:46,199
APIs. If you're doing something like
documents dot let's say a penschild or whatever.

452
00:38:46,679 --> 00:38:51,800
For those cases you should use the
renderer, and for the cases where

453
00:38:51,800 --> 00:38:55,239
you really need to access the dome, you should use the new functions that

454
00:38:55,280 --> 00:39:00,880
we have the after render and after
next render, which ensure that some functionality

455
00:39:00,960 --> 00:39:06,559
runs on the client side. But
again on top of my head, you

456
00:39:06,679 --> 00:39:12,199
usually discover those bugs like immediately because
you open a page and it cannot render,

457
00:39:12,280 --> 00:39:16,159
because you only have those problems if
you are calling those functions and life

458
00:39:16,199 --> 00:39:21,960
cycle hooks, Like if you have
a method that does some dom manipulation when

459
00:39:21,960 --> 00:39:25,360
the user clicks something, well,
the user clicking something is already in the

460
00:39:25,400 --> 00:39:28,960
browser. You don't have a problem
there. You don't need to wrap it

461
00:39:29,000 --> 00:39:32,000
in after next render or whatever.
You only have problem when you do dom

462
00:39:32,039 --> 00:39:37,320
manipulation and the constructor all saying engine
need and Joe after you need and some

463
00:39:37,519 --> 00:39:40,920
because those life cycle methods will be
called on the server. Okay, while

464
00:39:42,039 --> 00:39:45,719
server is rendering there, it will
call engine need because engine need maybe fetching

465
00:39:45,800 --> 00:39:51,440
data or whatever tool you know render
the component. In those cases, it

466
00:39:51,559 --> 00:39:53,440
means that if you have a problem
like that, you open that page,

467
00:39:53,440 --> 00:39:58,000
you immediately see an error. You
see that, oh what is document?

468
00:39:58,079 --> 00:40:01,360
What is window? I don't know, and instant immediate giveaway that Okay,

469
00:40:01,400 --> 00:40:05,880
that's the problem, and the solution
is also easy to take that code,

470
00:40:06,039 --> 00:40:09,280
put it inside after the next vendor, it will work in again nineteen nine

471
00:40:09,320 --> 00:40:14,400
percent of scenarios. Maybe you have
something super complex, which could be In

472
00:40:14,440 --> 00:40:17,480
that case you probably would put more
leg work. But in general, I

473
00:40:17,480 --> 00:40:22,199
think the transition to SSR, if
you want to do it on a fairly

474
00:40:22,280 --> 00:40:25,880
large project, you take a day
or two in general, because again you're

475
00:40:25,920 --> 00:40:30,199
not changing the actual code. Your
component codes are temperament, they will stay

476
00:40:30,199 --> 00:40:35,880
the same. You will just change
very granular pieces which might not even exist

477
00:40:35,880 --> 00:40:40,320
in your project if you're just doing
you know more bigger concern for libraries,

478
00:40:40,519 --> 00:40:51,039
that is, but not for you
know, enterprise application. So cool,

479
00:40:51,119 --> 00:40:54,719
that was a lot, Yeah,
yeah, but I agree, I agree,

480
00:40:54,920 --> 00:40:59,599
And for as you mentioned, for
everyone that wants to die to dive

481
00:40:59,639 --> 00:41:06,599
deeper into SSR. The last episode
was just about that, So you can

482
00:41:06,679 --> 00:41:13,119
check it out whatever you're you're listening
to the show, and we go way

483
00:41:13,239 --> 00:41:16,840
deeper on SSR in the last episode, so you're gonna really know if you

484
00:41:16,880 --> 00:41:21,400
should do it, how you should
do it, the caveats, pros,

485
00:41:21,480 --> 00:41:27,320
cons et cetera. So all that
that good stuff is there, and yeah,

486
00:41:27,360 --> 00:41:31,519
I think we can we can start
wrapping up from here. Yeah,

487
00:41:31,719 --> 00:41:38,440
let's let's do our promos verse.
And actually let's start with Arman because I

488
00:41:38,480 --> 00:41:46,280
heard he has something interesting. Oh, I have a long promotion. So

489
00:41:47,679 --> 00:41:52,039
for a long time, I guess
the last six seven months, I've been

490
00:41:52,079 --> 00:41:57,440
actually writing a book about Angular,
writing a book for the mining publication,

491
00:41:57,639 --> 00:42:04,800
maybe some about listeners about the publications. Fairly fairly popular, lots of amazing

492
00:42:04,840 --> 00:42:08,239
books stay ab out there. The
book is called Modern Angular, and so

493
00:42:08,239 --> 00:42:13,159
it's exactly what we have been discussing
in the last I guess ten to fifteen

494
00:42:13,199 --> 00:42:19,079
episodes. All the stuff that is
new and shining in the latest Angular versions,

495
00:42:19,519 --> 00:42:24,079
so standalone components, inject function,
signal, signal signals are is just

496
00:42:24,239 --> 00:42:34,159
interoperability, all the small stuff SSR, unique testing, template syntax, deffert

497
00:42:34,199 --> 00:42:38,360
loading, everything, everything that you
know about Angular starting from versions. I

498
00:42:38,360 --> 00:42:45,679
would say fourteen everything that is new
is in this book. Now that's how

499
00:42:45,719 --> 00:42:50,639
I know all these migration schematics Yeah, when you are writing a chapter about

500
00:42:51,280 --> 00:42:53,559
you know, say stand alone,
you've got to tell people how to migrate.

501
00:42:54,400 --> 00:42:58,159
The book is structured in that way. So in the book we are

502
00:42:58,639 --> 00:43:05,440
sort of coding along an enterprise project
with real life problems to solve, and

503
00:43:05,519 --> 00:43:08,719
we are using all the latest features, and each chapter, outside of just

504
00:43:08,760 --> 00:43:15,480
developing that part of the application,
also has how to migrate section. So,

505
00:43:15,599 --> 00:43:20,159
for example, for standalone components,
we build some standalone components in the

506
00:43:20,199 --> 00:43:23,079
project, we connect them, we
provide routing, we provide basedloading, and

507
00:43:23,119 --> 00:43:29,679
so on and so on, and
in the final part we have Okay,

508
00:43:29,719 --> 00:43:31,760
now we have a pro existing project. How do we approach this? What

509
00:43:31,800 --> 00:43:37,159
are the caveats, what are the
problems I'm an encounter, how the schematic

510
00:43:37,239 --> 00:43:40,159
works, what if I want to
do it manually? And essentially this works

511
00:43:40,280 --> 00:43:45,159
for almost all the chapters because all
the new stuff we're going to talk about

512
00:43:45,159 --> 00:43:49,079
how to migrate to it. So
each chapter has its own sub sections on

513
00:43:49,159 --> 00:43:53,880
migration. The book is now in
early access. The first three chapters are

514
00:43:53,920 --> 00:44:00,199
now available. Actually it happened today
yea twenty ninth of November. Actually you

515
00:44:00,280 --> 00:44:04,119
forgot about it, and they just
got an email that oh, you know

516
00:44:04,199 --> 00:44:07,840
your book is live. So the
first three chapters, the covering, standalone

517
00:44:07,880 --> 00:44:15,679
components, and the inject function pretty
interesting functionality. You know those chapters are

518
00:44:15,719 --> 00:44:20,039
live. I think I put the
links to the book in the chat yet,

519
00:44:20,639 --> 00:44:28,320
so let's have it in the absolute
description. Would love to see any

520
00:44:28,360 --> 00:44:32,360
feedback, would love to see comments. There's a live book forum, so

521
00:44:32,639 --> 00:44:38,320
if you have any questions, if
any comments, I will be active on

522
00:44:38,360 --> 00:44:43,239
the forum too, trying to address
all the stuff coming in from the readers.

523
00:44:44,599 --> 00:44:47,280
Hopefully anyone who want to try the
book out. I hope you enjoy

524
00:44:47,320 --> 00:44:52,039
it. I've put a lot of
work and a lot of love in it.

525
00:44:52,039 --> 00:44:57,119
That was really amazing experience. Yeah, looking forward for the other chapters

526
00:44:57,119 --> 00:45:02,000
to come around. Awesome. Yeah, congrats man, I know you've been

527
00:45:02,039 --> 00:45:07,320
working on it for a very long
time. I'm actually gonna send this here.

528
00:45:07,159 --> 00:45:10,679
Would it be okay to send it
in the comments section so that everyone

529
00:45:10,719 --> 00:45:20,519
that is that may be watching us
from streaming on YouTube linked eta and yeah,

530
00:45:21,000 --> 00:45:24,599
all right, the link is there. And that also make sure that

531
00:45:24,679 --> 00:45:31,440
we're not gonna forget to included in
the in the show notes, because now

532
00:45:31,440 --> 00:45:40,199
it's already in the comments. Actually, Arman I think there's I actually sent

533
00:45:40,280 --> 00:45:45,079
the the broken link. I'm so
sorry. Let me let me send another

534
00:45:45,159 --> 00:45:51,920
one with the correct one. Yeah, I was gonna just yeah, I

535
00:45:52,000 --> 00:45:57,400
included an open word at the end
that I broke the link. Sorry,

536
00:45:57,599 --> 00:46:01,280
Okay, nice? Correct? All
right again, huge congrats to you,

537
00:46:01,880 --> 00:46:08,079
and really for all of you that
are looking to improve your best practices and

538
00:46:08,159 --> 00:46:15,639
angular and just update yourself on the
framework. I highly encourage checking out Arman's

539
00:46:15,639 --> 00:46:20,440
book and just the fact that you
can read the first chapters for free for

540
00:46:20,559 --> 00:46:25,679
now, Like, this is such
a big opportunity for people to experiment before

541
00:46:25,760 --> 00:46:30,960
buying it, so like, don't
waste this opportunity. This is kind of

542
00:46:30,960 --> 00:46:35,760
having an open house. So yeah, definitely definitely check it out because this

543
00:46:35,880 --> 00:46:37,719
is going to be one of the
best chances for you to try out the

544
00:46:37,760 --> 00:46:45,880
content before you make a decision to
buy it or not. Yep, Chuck,

545
00:46:45,000 --> 00:46:52,280
how about you. So I am
right on the verge of launching a

546
00:46:52,400 --> 00:46:55,199
couple of memberships on top end depvs, and I think the one that is

547
00:46:55,280 --> 00:46:59,400
most relevant to this. So I'm
doing a React membership, but I'm also

548
00:46:59,440 --> 00:47:05,679
doing a jobvascript membership, and we're
going to have weekly or most well,

549
00:47:05,760 --> 00:47:08,079
it'll be at least three times a
month we'll have a meetup and we'll just

550
00:47:08,159 --> 00:47:13,320
we'll be on a zoom call,
and the calls are going to kind of

551
00:47:13,400 --> 00:47:15,039
rotate between three different things. One
of them is going to be a Q

552
00:47:15,159 --> 00:47:20,159
and a RIGHT, so I'll have
some of my expert friends show up,

553
00:47:20,280 --> 00:47:24,280
or I'll just answer your questions myself, or however that works. We're else

554
00:47:24,320 --> 00:47:29,239
going to have an expert show up
for one of the calls every month and

555
00:47:29,320 --> 00:47:32,119
talk to us about some aspect of
JavaScript or web development or something like that.

556
00:47:32,239 --> 00:47:37,960
Right. Incidentally, the other membership
I'm launching is the Ruby membership,

557
00:47:37,960 --> 00:47:42,280
and so the same idea rights.
The last one's going to be kind of

558
00:47:42,280 --> 00:47:46,079
a get to know you kind of
meet up, and then I'm also going

559
00:47:46,079 --> 00:47:52,920
to be having once a month more
of a career soft skills meetup that is

560
00:47:52,000 --> 00:47:57,199
part of all the memberships, and
so that's what I'm launching. It will

561
00:47:57,239 --> 00:48:00,599
also include a screencast series. I
plan on putting out a couple of videos

562
00:48:00,599 --> 00:48:06,079
every week, UH demonstrating some aspect
of JavaScript or web or tooling or something.

563
00:48:06,559 --> 00:48:10,440
So if you go to JavaScript Geniuses
dot com, UH, you'll be

564
00:48:10,480 --> 00:48:15,519
able to sign up. I just
bought the domain the other day and I'm

565
00:48:15,559 --> 00:48:19,280
getting it all pointed to the right
place. You can come see what it's

566
00:48:19,280 --> 00:48:22,719
about and come sign up. So, uh yeah, if you're interested in

567
00:48:23,000 --> 00:48:28,280
participating in that, then definitely check
it out. You can come see all

568
00:48:28,320 --> 00:48:30,880
the meetups and when they're scheduled and
all that stuff. You can just go

569
00:48:30,920 --> 00:48:34,719
to top endev dot com slash calendar
you can see all that stuff too.

570
00:48:35,159 --> 00:48:37,639
But yeah, that's that's the big
launch. That's the big thing that I'm

571
00:48:37,639 --> 00:48:47,320
working on right now. Nice,
nice, huge. Well I'm still the

572
00:48:47,400 --> 00:48:53,199
same, So my promise are going
to be if you're interested in staff fugmentation

573
00:48:53,400 --> 00:48:59,400
or software old sourcing. On void
U n v o i D dot com

574
00:48:59,440 --> 00:49:04,239
offers for performance based software development services, so the clients only pay when tests

575
00:49:04,239 --> 00:49:08,679
are delivered and approved, which currently
is the safest way for you to outsource

576
00:49:09,000 --> 00:49:15,320
or augment your stuff. Also,
they work on US time zones, so

577
00:49:15,440 --> 00:49:22,679
they are a near shore software development
agencies. They're not off it's offshore or

578
00:49:22,719 --> 00:49:28,480
offshore. I think it's offshore off
shore, yes, thank you, thank

579
00:49:28,519 --> 00:49:30,960
you. Yeah. The time zones
are not crazy. So if you end

580
00:49:31,079 --> 00:49:37,199
up choosing to work with onvoid you're
gonna know for sure that you and the

581
00:49:37,280 --> 00:49:42,039
engineers are going to be available at
the same time, which is really important

582
00:49:42,079 --> 00:49:46,199
for most companies looking to collaborate.
And yet I think this is all for

583
00:49:46,280 --> 00:49:52,199
today. I don't have anything else
to contribute to I think this was very

584
00:49:52,360 --> 00:49:57,920
in depth and yeah, again,
Harman Chuck, thank you so much for

585
00:49:58,039 --> 00:50:01,559
joining. It's always good to have
more roll on the show. Yeah,

586
00:50:01,599 --> 00:50:07,320
max out everybody, Thanks everyone,
Thanks everyone, and I'll see you in

587
00:50:07,360 --> 00:50:14,000
the next one. H