Hydration and Server-Side Rendering in Angular 16 - AiA 382
Jessica Janiuk is a Senior Software Engineer at Google. She joins the show to talk about Hydration and Server-Side Rendering in Angular 16. She begins the show by talking about her career and her achievements. She explains the process of how hydration works.
Special Guests:
Jessica Janiuk
Show Notes
Jessica Janiuk is a Senior Software Engineer at Google. She joins the show to talk about Hydration and Server-Side Rendering in Angular 16. She begins the show by talking about her career and her achievements. She explains the process of how hydration works.
Sponsors
- Chuck's Resume Template
- Raygun - Application Monitoring For Web & Mobile Apps
- Developer Book Club starting
Promoted Links
- Unvoid - Angular Experts - Design and web development services with enormous expertise in Angular for companies that truly care about quality https://unvoid.com/
Social Media
- Unvoid
- LinkedIn @unvoidweb https://www.linkedin.com/company/unvoidweb
- Instagram @unvoidweb https://www.instagram.com/unvoidweb
- Lucas Paganini
- YouTube @lucaspaganiniweb https://youtube.com/@lucaspaganiniweb
- LinkedIn @lucaspaganiniweb https://www.linkedin.com/in/lucaspaganiniweb
- Twitter @lucaspaganini https://twitter.com/LucasPaganini
- Instagram @lucaspaganini https://www.instagram.com/lucaspaganini
- LinkedIn: Jessica Janiuk
- jessicajaniuk.com
Transcript
SUBRAT_MISHRA:
Hey everyone, welcome to adventure in angular. On this episode, we have Jessica is from angular team itself. And today we have Arman.
ARMEN_VARDANYAN:
Hey everyone.
SUBRAT_MISHRA:
And as I already told you have Jessica Jenwicks. Sorry if I just spelled your name wrongly. So Jessica, just let us know why you are famous, what you do in Google, and what I think you breathe angular. You do angular always. You know deep inside. So can you just tell about yourself so our listener will be pretty happy to know about you.
JESSICA_JANIUK:
Sure. Hi, my name is Jessica. My last name is pronounced Janik. Everyone gets it wrong. We probably pronounce it wrong ourselves, because I'm pretty sure it's like a Polish name that would be pronounced very different in Poland. But anyway, yes, I'm a senior software engineer on the Angular framework team at Google. I've been working on that team for like, two and a half years, getting closer to three years. I've been an engineer for close to 15 years, mostly working in the front end space. I don't know that I would say I'm famous, maybe infamous. I don't know. I am fairly well known for my puns when I am present on live streams for Angular. Some people are aware of my hobbies, like I build robots for fun. Yeah, and otherwise, yeah, I work on Angular. I know it reasonably well. There's a lot that I don't know. I'm constantly learning. Turns out that when you build a framework, you don't necessarily use the framework. So... we have different insights as framework engineers than our framework users do. And sometimes we don't necessarily know all the patterns in which people use. So that's an interesting nuance of being a framework engineer. Yeah, I guess that's me and what I'm known for. You may have seen me on some of the Angular YouTube videos. I do those on occasion. And I do talks at a lot of different events. So you may also see me at those types of things. So prior to Google, I actually ran a Google Developer Group, which, if you're unfamiliar, it's Google has this whole program for people to run community programs. And you can volunteer and run a group for your region. And it was very rewarding and got me connected with a lot of really cool people. So I've done community organizing and worked for things like startups and other... non-tech industry companies well before I joined Google. And yeah, that's a bit about me.
SUBRAT_MISHRA:
Yeah, and I guess people can also Google you to know about you and you are pretty famous. So apart from that, like as Angular 16 just released, I'm sure you have worked on that. So in which area you have contributed the most for Angular 16 and can we have just put some lights on that.
JESSICA_JANIUK:
Sure. So, yeah, Angular V16 released exactly a week ago, today's May 10th, so May 3rd, I think, was when we actually launched V16 officially. And as part of that release, I worked primarily on the server-side rendering improvements that we have been slowly kind of trying to bring more focus on over the last year. Specifically, I worked on hydration and the hydration improvements. Essentially, prior to V16, we really didn't have a good hydration story on Angular, and we'd gotten requests. There was an open issue, and still is an open issue, asking for better hydration or hydration of some sort. The issue that's out there specifically talks about partial hydration. But before we could get to partial hydration, we needed to get to real full-app hydration. And I guess I should probably back up and say, if you're unaware of what hydration is, when you do server-side rendering of any client-side application, regardless of framework, you have a request that goes out to the server. The server does its own rendering, serializes all of the HTML that's generated. passes that down to your browser, so you get that fast initial rendering. But once that HTML is actually in your browser and rendered in your browser, there is a process by which the framework, whatever it is that you are using, now has to download and initialize. And when it does that, it needs to reconnect with all the DOM that has been... generated by the server. And that is the process by which we call hydration. It kind of hydrates your framework into the existing DOM structures. Otherwise, what ended up happening, which is what Angular used to do, it would essentially wipe everything that was there. So you'd get the... DOM, and then Angular would download, and then it would destroy everything and then re-render everything as the application initialized. So now, as part of our developer preview in v16, it doesn't do that if you enable it. It will kind of hook itself up into the DOM and just continue on. And that's huge because it offers a lot of benefits to things like Core Web Vitals. when you are trying to get better SEO performance. There was a known issue with flickering that people would have before because of that destruction. So like your DOM would be there and you'd see kind of a flash as it destroyed and repainted everything. That's no longer a concern. And so now it is overall a faster initial experience that people get. with server-side rendering when they have hydration enabled. So that's primarily what I worked on. There's a lot of details I could go into on kind of how
SUBRAT_MISHRA:
Mm-hmm.
JESSICA_JANIUK:
it functions. And I could talk quite a bit more about like where we're gonna go with it. But yeah, that's currently in developer preview and people can choose to opt in if they'd like. So, that's it for this video. I hope you enjoyed it. If you did, please like, share, and subscribe.
SUBRAT_MISHRA:
One question coming to my mind when I heard like the change of way angular hydrate before and now I think you must have monitored the how much like what is the percentage of speed or how much performance it will gain after you hydrate for a basic app so have any statistics on that
JESSICA_JANIUK:
It's going to depend on a lot of things. We've seen some apps that we've used that are even very optimized that
SUBRAT_MISHRA:
Mm-hmm.
JESSICA_JANIUK:
have seen like a 50% almost increase, or should I say decrease in time? Better overall, 50%
SUBRAT_MISHRA:
Yeah.
JESSICA_JANIUK:
improvement in. a number of the Core Web Vital Statistics across the board, but the only thing we don't see much improvement on is total blocking time, TBT. And we're looking at ways that we can improve that. But like your LCP stats, we've seen some pretty significant improvements there with almost a 50% improvement. And a lot of that has to do with the fact that it just renders sooner and doesn't get destroyed and recreated. So it can be picked up by Core Web Vitals as a more consistent entity. You don't see the, like, repaint that happens with the previous destructive version. But depending on how optimized your app is, how much dumb your app is, So if you've got a huge amount of DOM, how you've optimized it or where your bottlenecks are, it's possible you may not see a huge jump in performance because the bottlenecks were not hydration-related. The bottlenecks are elsewhere. And we have seen cases of that too where it's kind of roughly the same because of the way that the app is architected. So we're looking at ways we can... make recommendations for good patterns that people can follow with the app structure and how they can get better Core Web Vitals in a hydrated world. So if people are building giant components that have hundreds of lines of templates in them, it's probably not going to be as... well optimized as might be some others, some other approaches might be, essentially because the hydration process requires that we annotate all the elements that are there. So the hydration process, essentially, when the server is rendering before hydration with hydration enabled, it actually has to like look through the DOM and see what's there and generate special data annotations that are loaded into our transfer state object. And that set of annotations are used to do that kind of re-hooking up process that happens when hydration occurs. And if you've got a ton of DOM, there's a lot of annotation data. So I think there's kind of sometimes a balancing process. and you probably, if you can simplify your components, shrink them down in how much is in the templates, you'll probably have a better experience with hydration.
ARMEN_VARDANYAN:
So you mentioned, we talked about what hydration is in general. So what's the main difference between just hydration and partial hydration?
JESSICA_JANIUK:
That is a very good question. And the definition of partial hydration versus progressive hydration versus what people call islands, they're all slightly different depending on which definition you look at. The way that we are approaching partial hydration is being able to leave... certain portions of your application dehydrated until you choose to have them hydrate. So that might be something like, let's say you've got a bunch of components that are rendered below the fold, they're not visible in your viewport yet. potentially we would have a way for you to say, hey, render this on the server, but don't hydrate it until we've gotten it into the viewport. Or like maybe don't hydrate until there's an interaction that occurs, like if someone mouses over it. or something to that regard. That's kind of how we're viewing partial hydration, because right now when hydration occurs, it just it hydrates the whole application like eagerly as soon as you you load the application. But for us it's more like a deferred concept for partial, whereas it'll still do that for like most of the application, would you be able to specify which ones you wanted to be deferred. And along with that might come some lazy loading of the component itself. Because it doesn't really make sense to leave something dehydrated if you don't defer the loading of its code as well. Because if you're trying to save on like bundle size, you don't really save on bundle size. If you just defer the hydration of it, you kind of have to have to have both together.
ARMEN_VARDANYAN:
I see. So essentially, if I get it correctly, there is a way that when we enable this partial hydration that Angular running on the server will decide which parts to sort of send at the particular moment. I'm maybe using not very good words here, but I'm trying to get the general idea. I'm not really used to server-side rendering. We are in enterprise, no one cares about like Core Web Isos or whatever. I know about it, I tried it out once or twice, I think, but nothing really serious. So what my question was really about is, so now sort of Angular does use some strategy dehydrate and so on. Are there ways of... like hooking into that process because I have seen from the, I think the official blog posts of V16 that it's fairly easy to enable hydration. Are there more customizations that are available? Like for example, as we have preloading strategy for lazy loaded modules, is there some sort of... customization that the developers can do on iteration side of things or It all boils down to which modules are lazy loaded which are not lazy loaded
JESSICA_JANIUK:
Well, I should clarify that right now, all that lazy loaded behavior stuff is future, like
ARMEN_VARDANYAN:
Yeah.
JESSICA_JANIUK:
conceptual,
ARMEN_VARDANYAN:
Oh.
JESSICA_JANIUK:
we're not to the point where we can like do that lazy loading yet. We're thinking about it, that's kind of like exploration work we're looking at doing over the next six months or more. What we're looking at right now with what's available currently with the non-destructive hydration. is it's full app. It just hydrates the whole application. So there's no like deferred hydration at the moment. The only real lazy loaded behavior is essentially what was previously existing with, you can do it on a per route basis. So if you've got route navigation and you've got a lazy, like you're doing like a dynamic import on a component that is a route, that will like not cause a problem. It'll still get hydrated as soon as it's loaded. And we've been able to remove the need for enabled blocking when you're doing server-side rendering. And that's a huge improvement for people who were using it before, which was a flag that basically said, hey, if you're doing server-side rendering, block everything until... we tell you it's kind of okay, but now we've got more signals for when it's okay to actually do all of that work. So it's not needed anymore. So yeah, and I know it's not as common in enterprise, but we do think it's probably going to become more common. And... We definitely know there's been an ask. It's actually like hydration and server-side rendering performance has been one of the top, if not the top ask for Angular improvements for a while now. So we're actually quite excited to be able to put some time into doing this work. So now to get to your question about customization, at the moment, there really isn't much, much that you can do. There's a little bit with the configuration. So when you enable hydration, you're actually enabling a set of features, which includes the DOM reuse strategy and also the HTTP cache, which is something that we didn't have natively before. So the HTTP cache gives you essentially the ability to reuse the data. We offered transfer state before, where? So if you made an HTTP client request on the server, that data would be thrown into the transfer state, and when you got to the client, you would pull the data through the transfer state rather than making another request. But now it actually preloads a cache as well. So that data is cached for that request, and that also saves on having to make more requests in the future. So, those both are enabled when you enable hydration. The only customization you have now is you can potentially turn one or both of those off if you would like to. So, there's like with no DOM reuse or with no HTTP cache. We have been asked for some additional options in those configs and we'll probably... be adding some of those. We'll look at additional customizations down the road. But for right now, since it's developer preview, we're still working through the issues that come up. We'll see what we end up deciding on doing as far as when we stabilize the APIs. As likely part of v17, we'll end up removing the developer preview. That's another six months from now, so who knows what might come up in that time.
ARMEN_VARDANYAN:
This all sounds like a pretty huge performance improvement for server-side rendering. You think Angular is going to become more popular with less enterprisey projects and companies?
JESSICA_JANIUK:
We think it probably will. I think Enterprise is still going to be our main use case, but we have a lot happening in Angular right now with the announcement of signals as our kind of our reactivity primitive that we're starting to write into the framework. And we're looking at our change detection. We're trying to head towards. the ending, or that's probably not the right way of phrasing it, but not requiring zones anymore, if you're familiar with zone.js. So we are looking potentially to a zoneless future, and that's really exciting. These are a lot of things that people have asked for. It's been really heartening to see how excited people are about the direction that Angular is heading. There's a lot of buzz. about what we're doing right now. I think if you had talked to people around our V12 release or V11 release, there was a lot of negativity and commentary that wasn't super positive about the future of Angular. But now people are saying, oh, it's an Angular Renaissance, and there's a lot of excitement. And we're quite proud of that. We really are.
ARMEN_VARDANYAN:
Well, even
SUBRAT_MISHRA:
Yeah,
ARMEN_VARDANYAN:
the
SUBRAT_MISHRA:
I
ARMEN_VARDANYAN:
React
SUBRAT_MISHRA:
think.
ARMEN_VARDANYAN:
people are after us right now. That's all the talk on Twitter or whatever platforms.
JESSICA_JANIUK:
Yeah.
ARMEN_VARDANYAN:
Let's also appreciate the fact that we talked about Angular v16 and only after 20 minutes, we set the word signal.
JESSICA_JANIUK:
Hehehehe
SUBRAT_MISHRA:
Hehehehe
ARMEN_VARDANYAN:
Because I feel that Angular V16 is like this huge release and signals are awesome, but there is so much more stuff there. I was compiling a presentation for our office for a meetup to get the folks familiar with the V16 release. And there was just so much just in the blog post of the release. But if you go deeper about the plans, about all the discussions and It's really exciting right now. So another question is apart from...
JESSICA_JANIUK:
It shows this recording for me.
SUBRAT_MISHRA:
Yeah, for me as well.
JESSICA_JANIUK:
I bet it's because he left and rejoined.
SUBRAT_MISHRA:
So do you ask the question?
JESSICA_JANIUK:
Yeah.
ARMEN_VARDANYAN:
Yeah, I was going to ask that apart from those two big changes, what do you think is exciting about other stuff that is getting released? I don't know, maybe required inputs, for example, or smaller changes.
JESSICA_JANIUK:
Yeah, like required inputs is something that people have asked for for a long time. And I think what I love is the, like between that, between like migrations or things that were added like as a one-off, like, oh, I'm just going to do this minor little improvement that ends up becoming a huge thing. Like for example, I don't remember if it was V15 or V14. Alex Rikabaugh added a quick little PR that was like, ah, we'll just expose this inject function so that it does more than it did before. And it wasn't really thought of as like a big deal when he put that PR out. It was just like, oh, I'm just going to make this perform more consistently. And then suddenly the internet blew up about how, check out this incredible inject function and how it's changing everything. And we were like, oh, okay, great. Yeah, we're glad you like it. So I love these little quality of life improvements, especially when they are unplanned as being much of a big deal. Additionally, we've had a couple of new contributors like pop into the repo and start making some really substantive commits and changes. That's been really exciting to see as well, because it's not just driven by us since it's open source. We, as a framework team, of course, do Angular as our full-time job. We do really rely on community people to come in and make real big contributions, big and small. Sometimes people come in and just fix a spelling error. And other times, people come in and like, make some huge type safety change that touches 50 files and requires a whole bunch of review time. But we love it, we appreciate it. And I think that's the thing that is the most exciting for me is to see, at least when it comes to these smaller things, is seeing the engagement from the community and the efforts that they put in to make things better. So. Yeah, I think that's the way I would look at it.
ARMEN_VARDANYAN:
Yeah, I really love that Angular and lots of other related things like RxJS and NGRX are so greatly community-
JESSICA_JANIUK:
Well, all it takes is a quick pull request.
SUBRAT_MISHRA:
Yep. As you were discussing about the big things, I think if I remember when the IV came, it was a big thing that okay now angular bundle side will be less and then I think I heard a buzz about when everyone start talking about signals. Then slowly I think angular is also going as a standalone component now. We can get rid of John Jay's a lot of things is happening and It's it's good for us like To be honest When I was last last last last year when I intervened for for new jobs Everyone is saying that we are in angular might get to react or or or will Lot of jobs are coming with react, but nowadays people are thinking of Again, remake it back to Angular if it is possible because of the functionality or the power Angular gives for enterprise or for big applications.
JESSICA_JANIUK:
Yeah, I mean, we have always had a strong foothold for enterprise users, I think primarily because we have this whole concept of backwards compatibility and taking people with us as we move forward with all of the NG Update stuff. So it should be much easier to migrate to new stuff. And I think the fact that we publish our roadmap and that... we pride ourselves of being really stable. And part of the reason that we're as stable as we are is because we essentially can rely on all of Google to test for us before it hits major releases, because Angular is used pretty significantly within Google. And we've got just about every possible use case you can think of. inside Google. So when we make changes, it's pretty strongly validated already before we hit major releases. So we have this quality and reliability that is, I think a lot of enterprise folks benefit from that reliability that we get from that. But yeah, it's It's exciting to hear that people are still thinking of Angular. We've been around longer than most frameworks, and we're still trying to be as influential as we always have in this space. But we do recognize that people pick other frameworks, and they have lots of reasons they might do that. And It made me a surprise for people to hear that that's perfectly okay with us. We're not like, everybody should use Angular. We're great with people using other frameworks too. We actually talk with all these other framework creators pretty regularly, very regularly. In fact, I know Alex and Pavel from our team was on... the, like Ryan Carniato, if you're familiar with Solid, he's kind of like a big name in the framework space. He had a Twitter space and like Alex and Pavel were in on that Twitter space, so like they're talking a lot. I've been on panels with other framework creators before. It's like, we're not interested in like the framework wars. We're interested in moving the whole of. the framework space forward and being more collaborative. So I guess what I'm saying is, use what you're most comfortable with. We're thrilled when you use Angular and we're gonna continue to be there and try to be the best framework we can and try to give you the best features we can, especially since Ivy, I guess. I know there was a lot of perception before and during the whole Ivy work that Angular was kind of stagnant, and a lot of it had to just do with the fact that Ivy was massive. And so we had all these promises of, like, oh, Ivy will enable X, Y, or Z, and that's why we're doing Ivy right now, even though it's like a rendering engine replacement, so it doesn't really give you any new functionality, but it's better. We promise, we promise it'll be better for you. So it wasn't until all of the massive effort that it took to get Ivy to be the default everywhere that we were able to actually really start to move forward on all the features that people have been asking for. And that's why since like version 13 and 14, you've been seeing bigger and bigger and bigger releases from Angular because we no longer have to worry about Ivy and we can actually start delivering on all of these promises from earlier. So, yeah.
SUBRAT_MISHRA:
yeah I would like to ask a lot of people might have this question it sounds little funny but when I was like started angular I just thought of like is Google inside Google you guys are using a different kind of angular and you have a lot of feature then it got released and you start and do you guys like do Google limit the feature to the public and use lot of feature as a internal stuff or it's all public always
JESSICA_JANIUK:
It's, I mean, it is the same. You do not see a different version of Angular internally versus externally. So, I mean, there's different infra inside Google, so the experience might be slightly different, but otherwise it's still the same framework, internally versus externally. It's not really anything different. There are other internal frameworks that are used, but. the Angular experience isn't vastly different. We certainly don't have special framework features hidden behind some magic wall. And what's fascinating, I think, probably to a lot of people is that, unlike externally where we do like... patch releases every week, we do majors every six months, we do minors a couple of times between all of that. Inside Google, most of the changes that are made, once we merge them into the GitHub repo, that's what people use inside Google right away. So we necessarily can't have a change that breaks anyone. So we have to be even more cautious about the work that we do and the work that we land in the GitHub repository because of that.
SUBRAT_MISHRA:
As you told about you guys are talking with the external framework API so have you also got a chance to talk with analog as you are talking with about SSR so anything analog is a starting framework for like Nexus for Angular.
JESSICA_JANIUK:
Yeah, Analog's a meta framework. And yeah, we are aware. And we know him pretty well, the creator of Analog. We'll probably see him next month at ngconf. He was in the comments pretty heavily last week during our launch livestream for v16. So yeah, we're in communication with them. We actually aren't, like most of us actually haven't played with it. We probably will in the coming probably couple of months. But yeah, we're familiar with analog and we're thrilled that it exists.
SUBRAT_MISHRA:
So analog insights use Angular Universal or it's a different kind of framework. So let's see what we can do.
JESSICA_JANIUK:
That, I don't think it, I'm actually not sure. I haven't actually looked at the ins and outs of analog and how it works. I know it's using some different infra. Like I think it's using file-based routing as opposed to the typical Angular router.
SUBRAT_MISHRA:
Mm-hmm.
JESSICA_JANIUK:
So it probably has its own server setup. So it's probably not using universal per se, but it is likely, well, it has to be using like the... platform server package within the Angular framework, which is essentially our abstraction for a lot of our server-based APIs. The universal is most of the server-based stuff, but it works in conjunction with the APIs that we actually have within the framework. So we have platform browser, platform server, and platform server handles things like transfer state and the... server-side DOM emulation library that we have is all integrated within Platform Server. So the actual rendering behaviors comes out of Platform Server, as opposed to it's not housed in Universal. So people can use actually completely separate from universal server infrastructure if they want to and still get server-side rendering working. It just so happens that universal is probably the easiest way forward for getting started with it unless you're already using analog. So my guess is he's got a bunch of stuff set up that's unique to analog.
SUBRAT_MISHRA:
yeah I was thinking while we were discussing about the hydration I had a question in my mind was so according to you what should be the best approach suppose you have a page so we should hide it only those component which are on the viewport and then load it later once it get to the client side or we should hide it the whole page then load it like that to load it in the client
JESSICA_JANIUK:
Well, for right now, there is only one option. There is hydrate the whole page. We don't actually have anything for deferring, deferring hydration on individual components or portions of your page yet. That's all future exploration work, and we're hoping to have something experimentally a little bit later this year, but we've got a lot of work to do there. So. The answer is, for right now, if you use hydration as it is in developer preview, you're just going to get full-app hydration. So whether it's below the fold or not, it's going to get hydrated. There are some limitations. I shouldn't say limitations. It's caveats, really. So prior to this, Angular, on the universal side, when we do server-side rendering, it's been very permissive as far as DOM manipulation. So if you've got a component, and the Angular APIs maybe are limiting you on what you want to do for a specific component, and then you decide you want to use an element ref to get access to your DOM element, and you decide you want to detach a DOM node or create a new DOM node and append it somewhere using like... document.createElement or document.appendChild or insertBefore, something like that. That was fine on server-side rendering before hydration because we have this DOM emulation library that allows you to do that kind of thing. However, with hydration, there's a problem because hydration relies on the... the APIs of Angular, the creation and update APIs of the Angular framework. So if those elements are not created using framework APIs and they're moved around on the page, when the server annotates what's there and hydration happens, there's suddenly new DOM nodes where it wasn't expecting. And it's actually going to cause hydration problems. It's going to break your hydration. So. Along with hydration, and you'll see this in the hydration guide that's available on Angular.io, these are patterns that we want people to start avoiding. There is an opt-out mechanism for components, so if you need to do that kind of manipulation, you can add this ngSkipHydration to the host bindings or as part of the root of the component. and it'll revert that component back to its previous non-hydration behavior where it gets destroyed and recreated. And essentially that allows it to move forward, but you don't get the benefits of hydration for that component. And we're looking towards a future where maybe DOM emulation on the server is not a thing anymore with Angular because... Turns out we're the only framework that does that. Like, it used to be common, but zero other web frameworks right now use a server-side DOM manipulation library. What you see in things like React and Vue and Svelte is they disallow the sort of DOM manipulation. cases like that, it's considered, especially in the server side and hydration case, as a bug. If you do that kind of manipulation and you get that error, the framework will try to recover, but it is a bug. You're told in their documentation that it should be addressed. You need to fix that. So you shouldn't be doing that in their code. And in the React case, they don't actually fire off their lifecycle hooks on the server at all. So... we're looking at what we can do to essentially end the need for domimulation on the server
SUBRAT_MISHRA:
Mm-hmm.
JESSICA_JANIUK:
and how we can approach patterns better in this case. So along with that may come like new lifecycle hooks for us or maybe some aspect of signals render effects we'll consider for signals-based components that allows you to... only do DOM manipulation like that on the client after hydration is completed. So that's one of the biggest caveats of hydration in general. But it shouldn't be surprising to people who have worked with other frameworks or have done server-side rendering and hydration with other frameworks because it's essentially a standard practice everywhere else.
SUBRAT_MISHRA:
Yeah.
JESSICA_JANIUK:
Don't do DOM manipulation on the server. So... I know that's more of an answer than you were asking for, but
SUBRAT_MISHRA:
Yep.
JESSICA_JANIUK:
yeah.
SUBRAT_MISHRA:
and you are seeing something. We had some reason.
ARMEN_VARDANYAN:
Yes, sorry about that.
JESSICA_JANIUK:
Sound good?
ARMEN_VARDANYAN:
I wanted to ask about, we touched a bit about Angular source code and everything. So I'm not really that big of an open source contributor. I've contributed documentation to NGRX, I think, quite a bit, but not really writing code and stuff. But I like reading. code and I read lots of different stuff inside the Angular repositories and that helped me quite a lot during development and understanding some less known features. Sometimes you see something in the source code and say, oh, I didn't know this could do that. So I was thinking about writing a series of articles exploring different... different features of Angular, but from the source code perspective, like how it works under the hood, like the exact code. They came up with some stuff about, for example, the ngf directive or the async pipe, some very popular things that are more or less easily accessible for people who want to try to understand how it works under the hood. But you obviously know more about Angular source code. So what are some other parts that newcomers to source code could read and try to make sense of it? What are some good rules about navigating through the whole thing?
JESSICA_JANIUK:
That's a really good question, and it's actually something that a lot of newcomers to the Angular team itself struggle with because it's complex. And it's been deeply optimized in ways that can be kind of hard to follow. I can tell you from personal experience, several of us on the framework team when we joined, we looked through the code base and went, what the heck is an L view? What's an L view? Why is there a T view and an R? What are these R structures? Like, is it a left view and a right view? What do these mean? Why are they arrays? And the answer is no, it's not left view and right view. It's logical view and render view. But it's unclear that that's what they are when you first look at it. So... it can be a little daunting looking through what's there and being like, I don't understand anything that I'm seeing here. But in a number of cases, it's actually pretty well documented. So definitely read all the comments if you're going to look through it. If you want to be a contributor, we suggest looking through the issues and finding something that says something like good first issue or help on it. those are great places to start because they're going to be less complicated than some of the other big issues. I wouldn't suggest looking at some of the big long-standing issues that have been open for, you know, five years because the reason that they're still open after all that time is because they're deeply complicated and will require a lot of work. So that's probably going to be too much. But some of these great first issues are a perfect place to start. There's nothing wrong with starting with documentation as a way to understand how to contribute. So we recommend that as a good understanding the contribution process, because we have our own processes for, like here's how you structure your commits. Here's like you need to go sign the Google CLA, you need to like do X, Y, or Z. And a simple commit using using some documentation is a great way to clear that hurdle because it's not a big hurdle, but it can be a little confusing. We follow a rebase pattern. So we'll see, people will make a commit and then they'll be like, oh, I'm behind heads, so I'll merge main into my branch, but they don't realize that that shows a new merge commit in their pull request. And that's... not the thing we want to see. So they're going to end up getting a comment from us saying, hey, could you rebase on main? Could you fetch and rebase on main? And then people have a hard time with like, oh, well, I don't know how to push these changes now. So they'll end up closing their PR, creating a new one. So it's a big rigmarole. So starting with something small to get your first PR in. and getting over those hurdles to understand the process is a good recommendation. Then jumping into good first issues for actually digging through the code. Take something small and take it centralized into one specific area and write tests. Please write tests. If you want it to land, make sure you've got some unit tests or an integration test. because you're probably going to get asked for it if you don't have it there. We really strongly rely on it. We probably won't accept a contribution that doesn't have some sort of test verification in place. So that's a strong recommendation. And I guess the other thing I would say is if you're confused about something, there are places you can ask, there's people you can reach out to, so don't feel like you have to struggle through it trying to understand it, getting confused. Just post a question. Like there's a Slack we have for some... Contributors, that's a place you can go. There's our Discord, it is perfect for asking questions like that. Highly recommend joining the Discord if you're gonna do contributions and wanna get clarification on how certain things work. So, hopefully that answers your question.
ARMEN_VARDANYAN:
Yeah, that was really good advice. I remember I had to commit something to the Angular code base. I needed to add myself to the AngularGD list. And it was harder than I thought because I had some issue with the Google CLA. And I forgot about it because it was like two years ago. And now when you said Google CLA, I was thinking, what is Google CLA? It sounds so familiar. I remember that I for whatever reason I don't seem to recall but I I couldn't get it get it to work it there was this there was this boat that was pinging pinging me all the time that they cannot merge this until you have the CLA thing figured out I don't remember how I fixed it though I always remember the problems
JESSICA_JANIUK:
Yeah, the CLA can be a difficulty that some people encounter. It should, as long as your email on GitHub is consistent with the one you sign the CLA with, it should be fine. We have had rare occasions where the bot doesn't function properly, but usually we can check to see if you've signed it and resolve it. But essentially, if you're curious what the CLA is, it's essentially a license agreement that Google requires to let you sign if you want to be a contributor that basically says, you know, this contribution will be essentially added to this open source repo. The license is with how Google has licensed it, and it's safe to be used in Angular that you don't try to claim ownership of it because it's open source. It's just a requirement that we have. But it's not like it's a big barrier. You just have to go click a couple of links. But it can be confusing. I would say also when you make changes, some people don't realize this, but at the bottom of your PR, you'll see a list of statuses. And you may see like the red X, but you'll go down and look at the statuses and you'll be like, I don't see what's broken. There's an inner scroll. So scroll down in that list of statuses and you'll see what's broken. And you should be able to click through and see the details. It's a UX thing about GitHub that isn't necessarily the most transparent, or maybe it's too transparent because people can't see it. But yeah, that is another point where people are like, it doesn't show that my tests are failing. Well, it does. You just can't see them because you haven't scrolled down. So yeah, that can be a stopping block for some people.
ARMEN_VARDANYAN:
One has to really appreciate how organized the code base is with all those processes and checks in place because managing that large of a repository with so many packages, dependencies and tests and everything Yeah, I can only imagine that being really hard So yeah,
JESSICA_JANIUK:
Yeah,
ARMEN_VARDANYAN:
that's
JESSICA_JANIUK:
it
ARMEN_VARDANYAN:
really good Yeah, that's
JESSICA_JANIUK:
is.
ARMEN_VARDANYAN:
really good to have all those processes
JESSICA_JANIUK:
It's really helpful that we actually have a team of people that has built some really top-notch tooling for us to make managing this work a lot easier. We've got special command line tools for caretaking. So what happens is like every week there's a new caretaker for the and releases. So during that process, we have some cool CLI tools that we're able to use to check to see what needs to be merged and to run the merge for us. And it checks all of the branches and makes sure it's safe to merge and so on. So it does make it quite a bit easier for us. We don't have to manually click a merge button and then realize, oh, we want this to go in both main and... the previous patch version and the next RC or whatever it may be, it figures it out for us based on a couple of labels that we've put on the PR and then does all of the cherry picking and merging for us so we don't have to deal with that stress. And we're really grateful that we have a group of people that maintain that.
ARMEN_VARDANYAN:
Wow, that's a real...
JESSICA_JANIUK:
It's kind of like an on-call, but with less stress. It's not like an on-call situation where, oh my God, I've broken something, it's 10 p.m., I need to quickly come in and fix it. The caretaker's pretty laid back because it's really only during business hours of the person who is caretaking. And they're really just running a couple commands to land stuff into the repository. The only issue that we might encounter is if we like break someone, we have to do a quick little rollback, but it's not like super, super stressful. So yeah, I like it because it keeps us closer to, it's not like we're like, you know, these like... people so far away from the daily processes of the work where we're just like writing code and like shoving it over here and somebody else does that work. Since we all have to cycle through it, it's all part of our duties and we see things that go in, we have to work through the problems with contributors and we have to interact with people on their PRs. And I like that it keeps us closer to our community in that regard. The caretaker term is actually taken from Star Trek. And if anybody's familiar with Star Trek Voyager, there's the very first episode of Star Trek Voyager, there's this creature they encounter called the Caretaker. Our former engineering manager, not engineering manager, he was our former TL, team lead, Igor, before he left. He's a huge Star Trek fan and it came from that.
ARMEN_VARDANYAN:
Yeah, interesting. I didn't see any of anything from Star Trek. I used to like Star Wars a lot, but my sister who I mentioned is also in the United States. She loves Star Trek, but she never managed to convince me to watch it. And I know that it's a big commitment, so I just don't start it.
JESSICA_JANIUK:
Well, I would encourage it because it's a wonderful franchise.
SUBRAT_MISHRA:
Okay.
ARMEN_VARDANYAN:
So what do you think guys?
SUBRAT_MISHRA:
Yeah I think if nothing... Sorry sorry Arman, you're telling something?
ARMEN_VARDANYAN:
Yeah, I was asking... Nah, I was asking if you think we should now do promotions and peaks.
SUBRAT_MISHRA:
Yep, yep. So I was just saying that if nothing else we'll proceed to the end of the podcast. So for Jessica we have a structure of first we'll promote like promotes means if you're doing something new some something awesome we'll just tell about that then we'll go and have a picks. So in picks you can pick any books any stuff any movie any series anything you like.
JESSICA_JANIUK:
Okay.
SUBRAT_MISHRA:
so so I think we'll start with Arman any any promotion anything you have
ARMEN_VARDANYAN:
gonna say the same thing I've been saying last four podcasts not yet but I have possibly something exciting up my sleeve so I will just say that again hopefully in several
SUBRAT_MISHRA:
and
ARMEN_VARDANYAN:
weeks I will get there
SUBRAT_MISHRA:
Yeah, keep it up. And what about you, Jesse?
JESSICA_JANIUK:
I guess the obvious promotion is, you know, go try out V16 and try out hydration. Let us know if you have any issues with it. Please file bugs. Please, when you file bugs, create a reproduction for us that's critical for us to be able to address anything. And yeah, I guess I hope to see you at... an event at some point soon. And we're excited to see what you all make with Angular. So that's my promo.
SUBRAT_MISHRA:
yeah that's cool about me again i would like to promote my channel here like fun of heuristics so it's mostly up on angular you guys go and check that one uh lately i am i move i am in a vacation to india so all my gears and everything is in amsterdam so i'm not able to put any videos right now but soon I will try to put only screen recording and put some video I have some pending videos already recorded but didn't have time to edit them so that's the promotion for me and I will start with the picks again so I was just going through a book that is I think is a famous one, it's Grit by Angela so it's saying about passion and perseverance and lot of great stuff so please go and have a read if you get some time so do you have any picks for us tessica anything you like
JESSICA_JANIUK:
Probably nothing in the tech-related area because...
SUBRAT_MISHRA:
Yeah anything like movies, series, cards, games, anything.
JESSICA_JANIUK:
I just have to say Star Trek Picard season 3 was amazing. I highly recommend watching it. That was probably the highlight of my recent weeks and I'm also very excited for the new Ahsoka series, the Star Wars Ahsoka series. So those are my two picks.
SUBRAT_MISHRA:
What about you, Amman?
ARMEN_VARDANYAN:
I'm not really sure about whether what I'm going to talk about is readily available to consume. I don't know, but we have our office arranged. It's a bit tech related, but not exactly arranged for us to attend. Well, it's a long running training program for leadership and team leads, usually specific for tech related companies, but not everything there is just tech related. It's called Stratoplan. And I'm usually not that big of a fan of all those, you know, really leadership trainings and stuff, but that one was really good. They, they're, they used to have a company in Russia, but they moved, I think, like five years or six years ago, they moved to Portugal. So it's essentially a Portuguese company, but they have different offices here and there. So they have a training that's just called team and it's usually for, uh, IT team leads and stuff. It was very interesting because it was on a really empathic level, it wasn't this corporate thing, but rather how to better understand people around you and how to sort of respect their boundaries and also help others to understand each other better, how to understand if someone has problems inside your team without intruding or whatever. And it was really cool for me because they guys kept talking about some sort of problems or some doubts that they had with their team. And then I would think, oh, you know, I had that with my team. I have seen that in my coworkers. Now I sort of understand better what could be the reasons for such situations and so on. So yeah, I'm gonna pick Straddleplan. try to find some useful links they have they have a large blog with lots of this leadership related stuff yeah i seem to enjoy it so yeah that's gonna be my pick for this week
SUBRAT_MISHRA:
cool I think we have reached the end of this podcast this was a very informative discussion Jessica like we learnt a lot I think we might go and try to give generate some pull request and all of us and who are listening from my side I am saying will remember to write tests that is important and
JESSICA_JANIUK:
Please do.
SUBRAT_MISHRA:
yeah so till next time see you
ARMEN_VARDANYAN:
Yeah.
SUBRAT_MISHRA:
guys bye bye
ARMEN_VARDANYAN:
Thanks.
JESSICA_JANIUK:
Bye.
ARMEN_VARDANYAN:
Bye.
Hydration and Server-Side Rendering in Angular 16 - AiA 382
0:00
Playback Speed: