Track 1 Day 2 Livestream | AngularConnect 2019 | Sponsored by ag-Grid

Track 1 Day 2 Livestream | AngularConnect 2019 | Sponsored by ag-Grid


.
. .
. .
. .
. .
. .
. .
Good morning, and welcome to AngularConnect, 2019, day 2. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. – Hello, everyone. Good morning!
Welcome back to AngularConnect. We hope you had a great day!
We’re losing our cameraman already.
– Good morning. It’s great to see you made it back in.
– Particularly after the bar crawl. It went on later than we
expected! Okay, so, yesterday was such a great day. I had an
amazing time. I hope you did too. We’ve got photographs – Igor in
the wild. We had amazing talks, some of the best talks we’ve
ever had here. Also, expert zones was really great.
– Some of our youngest AngularConnect members. I hope you got a chance to
experience those awesome things. It was an awesome day. We’ve got
prizes for tweets at the end of today. We did really well on the
hashtag AngularConnect – #AngularConnect. Get on Twitter. – You might have noticed that
our theme is Under The Sea but we thought
we could double down and make it better. Last night, we went went out to
Woolworths and bought a blow-up turtle. This is nothing to do with us,
although they’re really on brand! This is for the climate
march that’s going to go on today. You can wave for them and be
sustainable as well. We’ve done a fantastic job,
everyone has been wonderful. We’ve all kept to the code of
conduct. Let’s keep it up today. If you do have a problem, find
one of the green staff members, or just get in touch with Megan,
but I think we’re good there. – I’m really enjoying our new
expert zones, and hopefully you guys are too. If you haven’t had a chance yet,
go and take a look downstairs. We’ve got another couple running
today, and a couple of mini workshops. If you wanted to attend those,
take a loan at the website to find out more information.
– We had a fantastic community lunch yesterday. The feedback
was really good. If you would like get involved
in the diversity lunch, it’s in the mini workshop room. We have
food stations in there. This morning, we are starting
off our mindfulness sessions. Those are in the quiet Room,
kicking off at about 1045. If you want to just chill, get down
there. – So it’s time for another
Sli.do poll. Phones out again. Head on over to slido.com.
You’re all masters at this. The question is: what is your
favourite operating system? We will try to get the results on
one of these screens. That was quick! Getting good at this,
everybody! This is great its. – Come on, MS-DOS!
– Steve Jobs will be happy. Windows is creeping up. This is
interesting. No more windows in there we go. That’s I thought Mac was going
to win by more than that, personally. It’s good to see a
good distribution. – If we add MS-DOS to windows!
So now you’re on Sli.do. It’s the perfect opportunity to start asking the panel questions, so, later
today, we’re going to get almost all the Google team up here to
answer your questions, and you can submit questions now through
Sli.do. – Before we get on with the
keynote, we have to thank our wonderful sponsors, ag-Grid, our
premier sponsor and our wonderful ones. We simply couldn’t do this event
without them. If you haven’t had a chance yet,
their booths are out here and you could you should go and
spend some time there. I think it’s time to get on. Our keynote this morning is with
the wonderful Minko. He joined the Google team just
over a year ago. Before that was he was doing
fantastic work. Now he’s developer-advocate at
Google, and he’s going to come and tell us more about what’s
been happening on that side of things. Let’s put our hands together and
welcome Minko on the stage! [Applause]. [Music].
– All right. Hello, everyone. My name is Minko Gechev. I’m a senior engineer in the
Google. I’m truly excited to be here today. This is my first AngularConnect
as part of the Angular team. I’ve been here about five years
ago where I talked about
aspect-orientated programming. Today, we’re going to discuss
other topics – performance and tuning – but also mention the Angular in
pushing the web forward with Web Standards. So let’s get started. The agendafor today is we’re
going to discuss Angular, the web
platform, and our efforts in the standardisation, our connection
with TC39. We’re going to discuss how to
make an experience using schematics, enabling best practices, enabling
extensibility with a new builder API, and we’re going to look at specific
consolidates, at finally, we are going to discuss Bazel and how
you can build it at scale. A quick disclaimer: I’m in the
process of losing my voice, so if you
stop hearing it at some point, it’s probably not going to be a
technical problem. Let’s get started with TC39.
Often, when I talk to verse, it seems that people have the
impression that we are working in isolation without
collaborating with the other parties involved in moving the
web platform forward. That’s not quite the case. We have regular things with TC39
and W3C. We were one of the initiativairs who pushed the decorators forward,
the original proposals that are the
– that you are currently using and we are working with TC39 to
work the best for the JavaScript virtual machine and the ergonomic API aLuke you to
use decorators efficiently in the browser. Currently, yes active in the
standardisation process are different browser vendors. We have Internet Explorer,
Chrome, Firefox – all trying to contribute to the web platform
so we can build more powerful and reliable user experiences.
One of these browsers is, in fact, developed in the company
where Angular comes from. This is Chrome, and, lucky that we
have a lot of the intersection points with Chrome. We are in a constant
collaboration around how we can make the web
faster, how we can provide more rich
user experiences, and much more. I was just keying through the
meetings that we had over the past couple of months and we’ve been discussing
how to make powerful PWAs, web
performance, testing, and much more. One of the recent deliverables
that we worked on together is web. desk/angular. In this set of posts, we are
trying help you have guidelines on how to build performance and
progressive web applications. This collection of posts
contains information about how to build performant web
applications in terms of improving the time to
interactive as well as the speed of Angular
change detection, respectively run time performance. We are discussing how to build
more reliable applications by using pre-cache ing with the Angular service
worker, how to make the applications installable and
accessible. All of them are in the same
format. You have a bunch of content,
inter active examples and diagrams to
help you get started faster. If you’re actually interested in
performance, I would definitely recommend you to visit the
performance optimisation s in Angular today,
and, if you’re interested in the internals of Angular, and the
work that we have been doing there, definitely visit
Kara’s talk on how Angular works. Now let’s talk about tooling. We have been working on making schematics that are standard for transfer making the files in
your work space and bootstrapping your projects. Schematics can help us build
more performant applications as well by automating your
development experience by helping you to follow best
practices easier. … is publishing a regular survey
on the cost of JavaScript. While the most expensive asset
shipping over the wire is JavaScript. Definitely, we would want to
reduce the number of shippingings in order
to speed time to interactive. Probably the most efficient way
to do that is by using code splitting. I bet most of you are
familiar with this concept. You can load children in the Angular
route declaration, and from there, you can just load a
particular route that is not going to be used immediately
lazy. However, this involves a lot of
manual steps. We first have to define an
NgModule. We have to declare a laze why I y route. We have to declare a route in
the NgModule that is being handled
by a component, and, if we’re following the Angular style
guide, on top of that, we also have to deliver a routing
module. That’s a lot of steps that could
be automated by using schematics. So in Angular CLI version 8.1,
we introduced a command that will allow you to generate a lazy
route which is – with just a couple of characters. You can specify your module
name, you can specify the path that you want this module to
handle, and your parent module. Let me show you how this works. So, here, we have an Angular
application with a couple of routes. When we navigate to the route,
would be , we can see that we have zero network activity. There is absolutely nothing
being lazy loaded in this particular case. If we want to move this route to
a lazy route, what we can do is just go
to the console type, type in the name of the module, the name of
the route that it’s going to handle, and the name of the
parent module. Here, you can see we generate a new component, a new module, and
also the app module. Here is the lazy route that we introduced. Just a traditional standard lazy
route, and now we can get rid of the
… route because it’s no longer necessary for us to use.
Finally, in order to move the functionality out of our eagerly
load about component we can copy and paste this to the
lazy-loaded one, and everything from there on should work out
automatically. When we go back to Chrome, and
we navigate to the About page, we can notice that the browser
has sent an horribly http request download the modulettp request download the
module and download the bootstrap page. We’ve already been applying
schematics for ng apps, ng updates to
automate our migrations, and many others, including
bootstrapping your work space. But schematics can also help us
to build more intelligent tooling. Schematics with a combination
with some constraints that we are setting on top of the application structure so
we can get metadata about it. In order to look at the next
example, let’s first try to use the application with the lazy
route that we just introduced over a very slow network. You can notice that the user may
have to wait quite some time until
the they actually see the result. We’re putting in so much effort
to deliver desktop-like –
progressively loading the application, and, at the same
time, we deliver poor UX, right? In order to handle this issue,
we can use pro loading. While the user was in the home page,
we can load in the background the About module, so that, when
the user performance the navigation, it could be instant.
There are different ways to do that. We can preload all the modules
associated with visible links. This is a so-called quick-link
strategy. We can only preload the modules
associated with things we have hovered over, or we can apply
the most advanced strategy out there, predictive
prefetching, get the modules only likely to be needed next
based on statistical reports on how users are interacting with
our application. This here, the tool that I’m going to talk
about, it’s more and more for a community-driven tool. This is something in the spare
time we’ve been collaborating with Chrome so it’s not an
official Angular project, but it provides a really good example
of how, by combining different Google services, we can provide
more reliable user experiences. This is the so-called get jes. First, we are going to news NgRx
build plus. This is another extension built by the community
which allows you to plug into the webpack con figure ration of
your application without ejecting. After that, we can just edit the
extra webpack configuration that we want to alter our build with and
introduce the guest plugin there. All we need to specify is a
Google Analytics ID, a period for which we want to extract a
report for, and a route provider. This is something we
are going to discuss in a little bit. This is going to trigger the
build process we are familiar with. We’re going compile types, could
be catnate a couple of our files and run the guest plugin that will
require access to our Google Analytics report. Once we provide read acSouth,
it’s going to build our application and introduce pro
fetching constructions inside of the the individual bundles. We have been collaborating with
the Google Chrome team and with the
TensorFlow team in order to make sure that the model provides the
biggest accuracy possible. So next, we can just serve the application and open it in our
favourite browser and just to verify that,
the prefetching is happening in the right order. We can look at the net network
tab and see the about module has been
prefetched in the order specified in guess.js depending
on the likelihood for them to be used. So how does guess. .js works. It’s going to use a report from
your Google Analytics. After that was it’s going to
statically analyse your routing structure. This is only possible
because of the constraints that we have set on how we can
declare your routes in order to make them statically analysable. These constraints help us
provide better tooling for you – for example, types set with
other types of constraints, that can be quite useful. After that, we build a
machine-learning model which can be a chain or
neural-learning network and prefetch the routes in the right
order when they’re needed. Regarding constraints, I would
definitely encourage you to look at Rado’s talk on the power of
constraints. He’s going to talk more about
why we use static HTML templates, what
benefits other constraints, such as type systems can give us, and
much more. Well, talking about constraints,
another constraint we can set is performance budgets. So we can re strict – so we
optimised our application, right? We introduced lazy loading. Right after that, we used
prefetching and our application is fast at a given point in
time. However, we don’t have the guarantees that our application
is going to be fast a week from now, or in a month,
and a big percentage of application s performance regresses over time. Budgets are a great way for us
to improve this metric by monitoring our performance in a CI, so, with
budgets, we can set a given threshold for
how big our bundles are allowed to be and if our build process
for some reason exceeds this threshold, we can build our
build immediately and investigate where the failure
came from. I’m happy to share that in
Angular CLI 8.2 we introduced style budgets for components. We
noticed that a very frequent pattern is for people to im port … in
a couple of of their components which was increasing their
bundle size dramatically. In order to help you prevent
that, we introduced default values in our style budget. If your style exceeds a given
side, it’s going to automatically file. Let’s talk
about enabling best practices. Regard ing enabling best
practices, I want to start this part of the presentation by
sharing a small personal story about my first clerks to
Angular. In 2013, ontribution to Angular. In 2013, I was building a
single-page application and I noticed a small typo. I was excited to be contributing
to a big open source project. That was something I tried
before this moment, and I wasn’t really successful, so, anyway, I kept – I filed the
Angular repo, I fixed the missing brace. After that, I
wasn’t sure whether there was a missing brace, so I
removed the forked repo. I reproduced the example I believe for my local
editor, and I finally ended up opening this pull request, and I
started refreshing the page constantly in order to see
whether someone is going to approve it. So I spent like this
for a couple of days. Finally, Pete, who is organising
AngularConnect, he approved my pull request and it got merged
into master. That was a huge win for thee. me. I remember at how excited I
was at this pull request! [Applause]. Yeah! And, of course, that’s not my
own contribution to Angular now! [Laughter]. From this moment on,
I kept contributing more and more, developed a couple of
tools for static analysis but it was hard to ship big features
because team is holding some priorities, and we cannot ship a
feature out of nowhere without making sure what is –
not going to have any side effect, for instance. That is
why we introduced the collaborators’ programme with
some trusted collaborators. We tried to improve the engagement,
line help us – like, then. Help them help us build new
features and guide them through the process. One of the active
collaborators who played a really important role in version 8 in the CLI is Manfred. Together with him, we worked on
differential loading. After a couple of conversations
with the Google Chrome team, we discussed what would be the most
optimal way to implement this feature and finally we ended up
with the implementation that can pretty much improve your
time-to-interactive over 30 per cent depending on your
application. This is one viteaeof the
defaults that we tried to enable, so this in
version 8, we enabled it for all the versions out there. By using
schematics, we transformed your project structure, transformed
your work space files in order to take advantage of
differential loading out of the box. Another research for
enabling the defaults that we did was around serving. We looking at the HTTP archive
and we noticed a that a lot of the Angular applications out
there are not using content compression. Over 27 per cent are – that’s a
low hanging fruit that can save a lot of bytes to your users. We also noticed that even more applications are not using CVN,
and a lot of these applications are used globally. So probably
that’s another thing that you may need to consider. You want to deliver the static
assets to your users from the closest node to them. In order to enable all of this,
in the serving of your application, we started working
on NgRx Deploy, a initiative where we establish
with cloud providers and community members in order to
help you serve your application following best practices out of
the box. Here is an example of how this
works with Firebase. Here, in our Angular CLI
project, we are first going to add Angular
Fire. NgRx Add is going to trigger
installation of Angular Fire which is going to transform our
project, add some dependencies, and after that, it’s going to connect to the Firebase APIs. The next step, we can run NgRx
deploy and this run ng deploy and … once the build process
completes, it is going to pull our assets to
Firebase, and we are going to get a direct link where we can
see the result. So, on this feature, we started
early collaborating with Google Cloud and Firebase. We worked with Asia on ng
deploy, and now I want to invite – a quick demo. [Applause]. – Hi, everybody. Wow. I’m really
excited to be here. So I want to show you a little
project that I’m working on, and I will
give you the presentation mode. Wrong window. Where are we?
Sorry for that. Terminal … . So, we have here this very nice
Angular – where is it? Sorry. Here it is. We are working on this Angular application, and we want to host
it. We’re using static hosting, and,
like Minko said, we are working on
different platforms to deploy this Angular application for it,
and the Angular team has been working on the allowing
us to build this to add to the Angular
CLI that we can run the commands
with, and deploy it into different platforms. As I’m working on the Azure
platform as a cloud advocate for Azure, I
decided that this is the way that I will
bring Azure closer to the Angular community. So the project is called Azure
ng deploy, and you can find it on GitHub. And it’s published on nph. on npm. You have everything you
need to know here. Of course, it’s still under development,
and there might be some issues that you can help us with, but the important thing is you can
start working with it already. So, how do you do this? So I just want to show you the
project. Here it is. Okay, so this is an Angular
project, and you can have routing and lazy-loading, and
you can have assets, and everything inside – everything
as usual. And then, when you run – here’s
the app component – when you run ng add
at Azure/ng deploy, it will ask you several
questions. You can overwrite the existing
configuration. Let’s try this out. It will ask you to log into Azure to select the subscription, and in its default
mode, it will create the resources for you. It will create the resource
group that we have in Azure for grouping
resources, and it will create a storage
account where the application will be stored. And all the configurations will
be found here at Azure.json – the names of your subscription, the research group, the account,
and also which project you’re deploying, and the target that you want to run
before deploying, so the default is building the project, because we want to
get the build results with a
configuration reduction so you can change this if you have a
different configuration. Another thing that it does is
updates Angular JSON with the architect,
different architects, build is one of them, test is another
one, lint, and it adds the deploy architect. If you’re using Azure Deploy,
then this is what you’re going to see with
the configuration in Azure JSON and
host the at Azure. If you’re using other platforms,
you will probably see here some different configuration. Now, from the newest version of
Angular, it’s I think 8. 3, we have the command ng deploy
so we can directly run this, and hopefully, it will run without
many errors or bugs. So, like I said, first it builds
it, and we’ve been thinking about
how to do this, how to design this hole
tool of whole tool of – and I have the error of course! – how to design the what the tool does, and one of
the things, it’s whether we’re going to build the project
always before we run it or not. And, we’ve been talking with
Minko and the Angular team, and also other
people who are working on different versions of this tool, and we decided that, yes, we are
going to have to build the project every time so that you
will have always the latest version of it. And, of course, there are also
other things that we might use, and we are waiting for sure
feedback on this. Okay, so I’m giving here some
older configuration that’s going to work this time. And, so, it builds the project. It deploys it, and now it gives
you the link. And it’s just there on Azure. And you can all route to this
link. The link is composed of the name
of the storage account, buting you can
redirect it to your own URL, and that’s
it. That’s how easy it is. [Applause]. you can redirect it to your own
URL, and that’s it. That’s how easy it is. [Applause]. Thank
you. You can find us on npm. Just Azure/ng deploy. Please submit your issues, comments, anything you
like. I have to say that this project
is being built and developed by
advocates, so we are here to hear your opinions and hear your issues and demands,
and we’re going to talk to you about
it. We want to make this tool really
great for the community because this is what we love to do as
advocates. I would like to thank everybody on the team, on my team of cloud
advocates who has been helping me with this
project, and the Angular team that has
been doing the work on their side, on Angular, and Angular
CLI to allow us work to work on this wonderful thing
that enables us developers to do better and faster. Thank you
very much. [Applause]. – Thank you. All right, thank you very much
for the demo. As was mentioned, we’ve been
collaborating with a couple of partners from the beginning, not only big
cloud providers but also community partners, open source
developers out there. Another of our partners that we
are talking often to is the company Zeit. You may have heard about them,
developing the next JS framework on top of React. We’ve been working with the
Angular CLI GitHub pages deployment and Netlify as well. Recently, before I came to
AngularConnect, I saw that someone implemented deployments
to npm. If you’re building a library and
you type npm and ng deploy in the
Angular console after adding this package, this will publish
your library automatically. If you don’t see your favourite platform here, however, Jahannes
starts an ng deploy starter project. You can clone this, use the SDK
as your cloudy provider and automatically provide deployment
capabilities through the Angular CLI. Let’s briefly talk about
the extensibility of the Angular CLI. Angular CLI version 8, we
introduced a stable new architecture, builder API. It provides stability points to
Angular CLI which allows you to implement custom functionality,
and it often involves development of ng apps
schematics in order to add the custom builder
in your work space application file. Often when using builder, you
need to implement a function that does your custom feature,
and a schematic that introduces it to your project. After that, you can just run it
with ng run, the name of your application in the work space,
and the name of the builder. Let me show you what another
community member, Benjamin, did with this new feature. So we just create a new
application first. We call it desktop app. So this is a kind
of a spoiler with what he did. Once we installed dependencies,
we Kcan – this is going to perform some
transformations on top of our project structure. It’s going to
install some dependencies, and when we ng run
the desktop apps through Electron, we will get a
desktop Electron app directly that we can develop using
Angular and Angular CLI. There was a lot of creativity
from the community. We noticed that a lot of people
started experimenting with Jest,
Cypress, building – in fact, most
actually – in fact, all of the builder plugins are implemented on top of this or
architect or builders’ API that we talked about. If you want to learn more on how
to enable your custom functionality in Angular CLI, you can take a look
at our guides at … now, in the end, I want to spend
some time talking about building at
scale, and specifically Bazel which could be used in Angular CLI right now in
an opt-in preview with the new builders’ API. So, most of you are familiar
with what Bazel is. Let me spend a couple of minutes talking
about it. We’ve been using it internally at Google for over
ten years now. This has been building our mono
repo. When one submits a change list
to this among this, Bazel will subject the
other targets in the build graph. Bazel at the same time
will be able to execute this build in the most efficient way possible by analysing the
build graph and distributing it among
several cores or even cloud instances. In the same time, Bazel does not
understand any particular technology. It is being augmented with
different plugins. For example, if we want to build
an Angular app, Bazel is going to delegate the execution of the compilation
process to NGC or NGCT depending on
whether we’re using the current version of the Angular compiler
or Ivy. A couple of open source projects
using Bazel are Kubernetes, Selenium, and TensorFlow are
using Bazel in order to build their C++ codebase. We have projects from the Django
community well-NgRx, and we’ve been building Angular with Bazel
for over a year now. Joey is going to give you more
details in his presentation right after this one. So we are
pretty fortunate to be in the same company with Bazel as well,
and we have established a good partnership. Pretty much every Thursday at 9.
30, I’m joining a call with the Bazel team where we are
discussing how to enable building your applications at
scale. Currently, we have been
investigating what will be the best possible way to do that,
and there are two main things that we are looking at right
now: how to make it efficient for windows, and how to manage the build configuration
of Bazel automatically. So, let me share with you what
is the current layering since I
mentioned that it’s separate from the tech that we are
building. We have Bazel which is our build tool at the bottom. Again, it doesn’t understand
anything about … technology although it can build
C++, JavaScript, C, Objective-C,
Kotlin, so on, and so forth. It’s not coupled to any
particular technology because it delegates
the actual computation to a plugin
layer on top of it. These are the so-called rules. We have
rules for Angular, we have rules for Node.js and for TypeScript. On top of that, so now you
already, by using only these two layers, you can already build
your Angular application by using Bazel. You can use Bazel CLI, and you
can configure your build manually by describing the build
graph in the so-called build files. At ng Conf 2018, Bazel’s
integration with the Angular CLI was announced. This is the layer
at the top. So, by using the or architect,
or the CLI builders’ API, we’re delegating the execution from
the CLI directly to Bazel in order to handle your build
automatically for you. So, the new – the news around
Bazel that it’s going to be released,
it’s version one point old this month. The Bazel team is working hard
to make this happen and we hope it will get even greater
adoption when it is announced. Regarding the plugins for Node.
js and Angular, we’re still actively working on them. A lot
of companies have already integrated them as part of their
build process, but there might be some breaking changes
eventually. And about the builder API and
the integration with the CLI, that’s how pretty much it looks
like. We have the Angular CLI on top
which uses the builders’ API that delegates the execution currently to
Angular dev kits at Angular, or when you add
Bazel to your project, to Glastonbury similar Bazel. Angular/Bazel. Both will … to a particular compiler or
another one that’s going to perform the actions. So this
integration is still in Angular Labs. If you want to learn more
about it, and the Angular’s CLI integration
with Bazel, I would definitely recommend you to look at tea the talk about
the opt-in of Bazel. If you want to follow us for
updates around Bazel, I would recommend
you to subscribe on bazel.Angular.io or
request support from one of our trusted partners. At events, I’m often being asked
should I learn Bazel? People are often concerned because it seems
it’s the very complicated to start using. Angular. You need
to learn a lot of things, and Bazel is just another one. In
fact, you don’t need Bazel in order to use Angular, though. Bazel is just a build system
that’s going to produce production
executable assets out of your project. So, you don’t need to learn
Bazel, but it might be a good idea for your career
development, for your growth as a software engineer. It provides
you with a lot of great good practices from functional
programming, implemented as part of your build process. Where pretty much you have
purity and … everywhere in order to make sure that your
build process is as fast as possible. If you learn Bazel, it will
teach you a bunch of good practices and, at
the same time, teach you reusable skills that you can reuse when you switch your
job to a C++ developer, let’s say. So, as a recap, we are very
fortunate to be able to participate in the process of
moving the web forwards together with the different
standardisation committees. We are working really hard on
automating your development experience with schematics, working on
intelligent tooling which can help us to take advantage of different powerful
tools that can help you provide delightful user experiences, and enabling
best practices by setting the defaults. Also, if you’re
interested in Bazel, please follow up on
bazel.angular.io. Thank you! [Applause]. – That was a lot to take in, so
that’s a great start to the day. We are having a break now. We’re going to be coming back at
1045. Lots coming up on this track and
behind you this track 2. Also, our first mini workshop of
the day, and expert zone. If you want to check out the
schedule, it’s on the website, we will see you back at 1045.
Thank you very much. [Break]. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. This is a test.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. – Hello, and welcome back. So, up next, we have Joey
talking about GitHub at scale. So, let’s hear it for Joey!
[Applause]. – Hi, everybody. My name is Joey
Perrott. I’m Angular’s developer
infrastructure lead, that’s developer infrastructure for the
Angular team, not for everyone else, unfortunately, although a
lot of the same things do apply. Today, I wanted to look at a few
pieces of our infrastructure in tooling and kind of what we do to manage
such a large project on GitHub. Before we actually look at what
we do to manage things, I want to talk
about what dev means to me. First, as we all know, Angular –
part of Angular’s goal is to enable
developers to make great applications. So, dev i nfra enables Angular to make
developers make great applications. We help make people who use
Angular and efficient as possible. As I pecked, we are
pretty busiy on GitHub. Every week, we dev 125 issues
and pull requests. Much of this efficiency I like
to think comes from Devinfra work. Devinfra is typically a
black box for people. . if it is working properly, you
didn’t hear about it or don’t think about it, and you should
not need to. Today, we will look inside that
black box. Three things I want to cover:
closed issues, and how we are automatically locking those; building Angular
the Angular framework itself as fast
as we can; and also some of the ways that we consistently manage
our repositories on GitHub itself. So, first, we will talk about
keeping conversations current. So, here’s the problem: over
time, one of the biggest sources of noise
in our repositories is actually from people with comments that
happen with issues or PRs that have been closed or haven’t been
updated for a super long time. Someone comments “me too” which
isn’t helpful to the conversation, because it’s
closed, and people say, “I’m having this issue still” but now
we have actually fixed it so the context is not there any more.
It just creates a bunch of notifications for people that
results in us ask them just to open a new issue with new
context. So how can we actually minimise that noise? We minimise that noise by
encouraging people to have the conversation in the relevant
location. So, we can prevent reviving
these dead conversations and instead encourage people to
create a new issue by locking and leaving a message saying,
“If you’re still having this, go ahead and
post. ” I’m going to walk ahead how we
do this specifically in our repository. First, we have to
decide when we would lock an issue. So, for us, it became two pieces
of criteria: we only want to lock issues that are already
closed. We’re not looking to just stop
people from talking to us, or to say
that their issue isn’t important. This is when we’ve
already resolved something. And then, past that, we want to make
sure that the conversation has actually ended. So, for us, we decided on over
30 days of time where nothing has happened on the issue. So, now that we know what our
criteria are, we actually have to be able to discover what shows what those
issues are so that we can automatically lock them. We
looked around at what our options for doing this were, and
there are a few different examples of set-ups that have
already been doing this. Nothing quite fit what we were
looking for, and also, we’ve been looking for a way to test out GitHub Action,
so decided to use GitHub Actions for this. I’m going to talk through how
our GitHub Action works. Firstly, to find the inactive
closed issues. We do that using GitHub’s API. You’re likely familiar with the
syntax of what the queries look like. This is what happens in
the regular UI. We are going to check the actual repository we want to look in,
in this case, Angular will be Angular –
believe it or not, if you try to lock a locked issue, it does
nothing. We want to look for things that have been updated 30
days or more ago. So, for instance, for today,
that would mean looking at August 21st of this year. The
last thing is we want to make sure that we sort so that the oldest
issues first, or the oldest updated issues first. So that, if we have more issues
that we’re ready to lock at once, we start with the oldest
and work our way back. Now that we have this query, we
have to go and lock these discovered issues. So it’s
relatively simple as a process. We use – we unit a GitHub client
using Oktikit, and we use the query we
just made and search for the issues we are interested in, and
then we loop through all of those issues, and we lock them.
It looks easy. All you do is call lock issues. But what Lock Issue actually
does is we create a comment because we thought it was really
important that we explain why we are locking the issues, we have
the same comment that shows up on our of our issues that are
automatically locked and explains where we locked it, and
make sure we note that a bot has done this action and it’s not against
anything involved in tea the conversation. Then finally we
lock the issue. We just run this through our
repository like a con job and it will lock the issues. We have to
enable this for our repos, though. To do so, GitHub Actions are
configured using a YAML file. This is outside of the commit
number, I guess. This is actually what we use for
the Angular-Angular repo. We set it up to unevery day at
midnight, and we are able to just to reference the lock-close action
that we already created. So, we actually are now seeing
all these results, so, over the last three weeks, since we
turned on this, we’ve locked about 60,000 closed
inactive issues, so, for those of you who
were subscribed to our GitHub repo and I caused a lot of spam
to go to you, it’s over. You can turn your notifications back on. And, now we run it once a day,
and we are seeing a few a day, instead of this massive number. And I really want to make sure
sure that I note here, Charles is the one who wrote the majority of this code,
and I want to thank him for all of his work on it, since I
definitely am standing talking about it, but he’s the one who
came up with most of how we do it. Next, I want to talk about
how we build the Angular framework itself. So, it’s
getting more complex. If we step backwards and look –
the problem which as Angular continues to grow, it’s getting
more complex and bigger and that actually makes
it take longer to build and test all of the code. So we need to find a way to not
make it take as lock because that makes our developer
experience worse. If we look back now at
AngularJS, building was simple. We had a bunch of files, and we
combined them together, and we had our application. Were Angular, we’ve added this
transpiling that happens with TypeScript, so now we have to
take the TypeScript files, turn them into the JavaScript files,
and then combine them. That step of transpile or
building is really where the time is growing. ith Angular, we’ve added this
transpiling that happens with TypeScript, so now we have to
take the TypeScript files, turn them into the JavaScript files,
and then combine them. That step of transpile or building is
really where the time is growing. This is a simple
application of four files, for example, but let’s say we were
to up-David just one of those files. Then, once that file it updated,
we would have to transpile every TypeScript file again and
combine them together. It doesn’t actually make sense
because three of them, it’s the exact
same thing so we want to do this incrementally and only transpile
the files that have been changed, and just reuse the
results from before, and so you’ve heard this
talk a lot about how we use Bazel to do this but this incrementality concept
is something that Bazel provides but we feel it’s extremely valuable for
making builds as efficient as possible. So, as I said, that was a really
simple application but most applications I’ve seen at least
have more than four files. They can have hundreds of thousands
of files. Pretty quickly, we can become
CPU-bound because you can only be checking, or only compiling
one file at a time with TypeScript, so, let’s say with
my MacBook, it has two course, so hyperthreading, is to it’s a
really fast process but you have to go through all of them. We
want to scale this out horizontally. All these course
could be used for something more useful, or at least more
entertaining for myself. So, instead of building these
actions locally all in the machine, we can actually build
them using remote build execution and send all of that
work to the cloud. To some cloud executors to do
this. to some cloud executors to do
this. We could use however many cloud
executors we have and expand that out. Now, instead of building
locally, we are building these things to the cloud and getting
back results but if things are building to the cloud instead of
building on our machine, we would lose that incrementality
that we just talked about. To get that back, we do remote
caching. With remote cache, the build is
done and saved, any time we attempt
to build again, we do the same caching or incrementality
concept but just doing it remotely. One of the big
advantages here is that once we build it remotely, it’s available for anybody who is
building is it remotely. By using the same cache, all of
our developers and CI can build the same objects and not have to
build them for each other. Once I build Angular core 1, if
nothing has changed, nothing has changed, nobody should have to
build again, we can use just it over and over. Over the last few
months, we actually have set up remote build execution and
remote caching for the Angular repository. . We only take advantage of it in
our CI but we found on our unit tests we’ve seen a 33 – we’re 33 per cent
faster in running those. So, you can see how, at the beginning of
this graph, we are adding more tests and complexity, it’s
growing, and then around this point, we enabled remote build
execution and caching, and our graph went down. You might be thinking, Joey,
that’s not centred. That’s because there’s more to the
graph. I broke it. Then I fixed it. And now it is flatting out
again, so we’re good! So, it brings us to our next
topic. We want to move fast and break nothing. This is actually about how we
manage code moving into our repository. So, we need to bring in a lot of changes – as I mentioned, 135
pull requests each week – and we want to merge them as quick as
possible but we need to not break anything for our users. So
we need to maintain quality all the time. So, to be able to achieve this,
we attempt to capture and America nice as much as possible
everything we can for deciding when a PR is actually ready to
merge. We require code reviews for all
PRs, and we require that code review to come from someone who
owns the code been by doing this, we ensure that the code actually is maintaining the
quality we expect, as well as the conformance rules, and then
we also maintain that the code that’s been committed is
actually going where we want it to go. We are going in a
different direction because the code owner is responsible for
the direction of that portion of the code. We also do a lot of testing on
ControversialCI. We have code and commit
performance tests, so we make sure that
things like linting, and that the code that has changed has an
owner. ircle. We have code and commit
performance tests, so we make sure that things like linting,
and that the code that has changed has an owner. We make sure we create an npm
package that can be tested on repo. We don’t put it anywhere but we
make sure that that build is valid. We also run unit tests and
integration tests across multiple operating systems and
browsers. Because our documentation site is stored alongside our code, we
tested the documentation site for what we expect for every
build that happens. We talked in the past about how
Google actually builds using Angular Master. So, make sure that is possible,
we actually have to check that we
could won’t break anything in Google for anything we want to
bring into our repository. Lucky for us, Google is very
good at using code which I’ve decided to
call “creatively” and it leads to a very solid test to eat,
because what seems to be any possible usage of the code is
found somewhere in Google’s repository. We have hundreds of thousands of
tests that are checked for each PR before we merge them into
GitHub, and we actually are doing the same thing now for
testing Ivy, so we test vue engine code
and make sure that it passes 100 per cent, and for Ivy, we are currently at
just under 98 per cent so testing to make sure we’re not
regressing back. To maintain this, as I mentioned, we had to do this on all 135PRs
which is a lot of work. PRs which is a lot of work.
Additionally, we have more than 30 people who could
theoretically go to GitHub and press that merge button. This would be chaos if everybody
merged when they felt things were ready. Instead, we came up with a new
role on our team: the caretaker. The caretaker is responsible for
making sure that our we at the repo
stays in order. Because of the checks that we locked through,
if everything there is passed, anybody regardless of their
understanding of the code itself that is being merged can be
confident that, if all of those checks are passed, it’s ready to
be merged. And so, it takes away the responsibility of deciding
when it’s appropriate to merge it, and it just makes it so that
as soon as all of our checks pass, we can go ahead and merge
it. The caretaker is actually responsible for doing that
merging. They also monitor our CI,
categorise incoming issues so they can be triaged and
responsible for sinking those changes into Google, and for
releasing new versions of Angular at the end of their
rotation. So, it is quite a task, so we
actually have an internal application
that we use just to manage this process for ourselves. It allows us to create some
different sorting and different filtering around what we care
about to determine what is ready. It also allows us to keep track
of where things are going wrong and what needs to happen for
someone to get into the right state. So, it brings us to the last
thing I want to talk about: perfecting developer structure.
I know what you’re thinking. That’s a lot of success that you
talked about. You did it. You perfected it. No! It’s not
perfect. But, we have very well shown
that, by dedicating time to making sure
that our processes and tools get better, we are making things
better for the people who are making things in Angular. I
wanted to talk about a few things that I see as places we
can find impact next. We often talk about how the
Angular-Angular repository works but the reality is we actually
manage a lot of different repos within the
Angular org, so, if we can unify the process
that is happen across those repos, we can be more efficient
and reduce the overhead that it takes to manage all of those
things. So, also, with respect to the
caretaker app, with the help of one of our
interns this summer, we’ve been working on a new version of the caretaker app
that we hope to make available publicly that will give insight
into the progress of each PR so that people can see
on what is being done in a PR, where it
is in the process, and demystify things that are happening in our
repo. I want to automate everything. Ideally, we would automate
writing the code, but we’re not there. Cherry-pick ing things to patch
branches, replaces PRs, pushing new documentation and
automatically following up to ask for reproductions are all
things that we could start looking to automate to make
ourselves more efficient. Thank you. The slides are
available there if you want to look at the actually code for
our automatic locking. It’s available in our dev info.
Thanks. [Applause]. – Thanks very much, Joey,
interesting getting an insight there. Up next here, we have
performance optimisation s in Angular, and in track 2, the heart of humanising pull
requests. We are taking a bit of a longer
break between tracks – about ten
minutes – so, I think next door is still going, so, if we can
try not to disturb them, that will be great. Thanks very much. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. – – Hello, everyone, welcome pack. Grab a seat and we’re going to
get started. . up next, we are Mert who is
going talk about performance opened myself in Angular, and he will be in the
experts’ zone after lunch if you want to carry on the
conversation. Let’s hear it for Mert. Thank you. [Applause]. Up next, we are Mert who is
going talk about performance opened myself in Angular, and he
will be in the experts’ zone after lunch if you want to carry
on the conversation. Let’s hear it for Mert. Thank you.
[Applause]. – Hello, everyone. This is Mert. Let me start by explaining how I
got into performance opened myself. I work at Google, specifically
Google Cloud. And, for about four years, we’ve
been developing Angular, started
AngularJS but now we have mostly Angular
code. We have a lot of developers –
300 or so front-end developers – and
millions of lines of code. Somewhere along this migration,
we know the Angular pages are not as
past as AngularJS pages. It was surprising because we’re
using these shiny things, RxJS, Angular, all that. How comes
it’s slower? So, I had to spend a couple of
months investigating performance
problems. Before we go into these learning
I gathered throughout the process, I want to categorise
some components. Not all the anti-patterns I
discovered are applicable to all components. Like, so, most critical
components are list-like components which are
tables, tree select. If you have a lot of data going
into these components, it’s important that these components have good
performance because that’s where the data
is, and that’s where the problem is going to happen, and the
browser’s going to be slow, because of inefficiencies
in these components. The second most important
components are the components that go into
list-like components. So, if you have an icon that’s
in a table, a button, or a menu, it’s important that these are as
efficient as possible, but if you have some components that
just have a few instances on a page, it might be that you don’t
need any of these performance optimisation s, so just s, so just when just keep in
mind, when I’m suggesting patterns or anti-patterns, these
are the ones I used, the ones that we used within those. Let’s
get right into it. The first anti-pattern I like to
talk about is user detect changes.
Don’t use this. Just use mark for check. There are cases you want to use
the tech changes in, like attach or
reattach, but in my investigation of hundreds of components, we were
able to get the mark-for-check calls and the reason you don’t
want to use these is because the tech changes are synchronous. If you do this on a UI tread, it
will block execution until Angular
executes change detection on the subtree. You can batch it, you
can call it a thousand times if you want – it won’t do anything
until the browser gets to the next check. Mark for check doesn’t violate
the parent-child data flow which
Angular sort of seems … use on push, I saw in one talk yesterday, this was mention ed yesterday, OnPush is good for
change detection cycles. Another anti-pattern I would
like to talk about is usage of built-in
Angular directive when it is not necessary. For example, in the code on the
left side, you see ng class with a
binding that is hard coded. This is not as fast as just
using the class attribute by itself
because Angular has to initialise a directive and
maintain that object in the run time. Again, so this sort of
optimisation, it’s not that important if you do a component
that has a few usages, but if you do this on a component in
the table cell, and you have a table with thousands of rows and
cells, this is going to add up. Why is ng class bad in this
case? Let me back up a little business
and describe how ng Class works. That, like a lot of other
Angular directives use a helper class called iterable differs. It really tries really hard to
compare two arrays, and see what has changed. So, if you have, like, an array,
like two arrays like that, before it
finds if something has been added,
removed, or if it just changed index. It uses complex data
structures, but, like in the previous example, you don’t
always need this. Another example of this is ng
style. In here, we can just use a
simple bind ing to execute the same thing. ing to execute the same thing. Angular won’t need to use
IterableDiffers. Those thousand of iterables have
maps, objects, all kinds of data structures. Diff is this simple object which
doesn’t even need to. Weep that in mind. IterableDiffers. Those thousand
of iterables have maps, objects, all kinds of data structures.
Diff is this simple object which doesn’t even need to. Weep that
in mind.. – Keep that in mind..
– Hold on to that, if there are any changes that you want, make sure
you insert that view in the right
place, but you might now how your array
changes – items that change better than
*ngFor. It might be possible to achieve
better performance using just what *ngFor uses, without the iterable
IterableDiffers. You can even use caching. A lot of talks, a lot Feof
examples I shared it’s kind of like reinventing the wheel. If you do want to reinvent the
wheel, I say go for it. Just do it, because even if you
fail, you learn some lessons that can be applicable
elsewhere. But, if you do want to come up
with your own *ngFor, I would say
also add benchmarks just to make sure your work actually improves
things. It’s hard to beat *ngFor
efficiency, by the way. So, another anti-pattern that we
discovered is if you have a structure like this, where ng template is
within *ngFor, it turns out Angular does something
interesting. For each item in this array, it creates a new ng template and stuff. If you have 1,000 items, a
thousand ng template instances. In all cases, you can move ng
template outside of *ngFor and that would
mean one directive instead of however many items you have. So this is an another
anti-pattern that we discovered while investigating performance degradations in ng 2
migration. Sorry, I call it ng 2 – Angular. So this is an interesting case,
because it’s like RxJS is really good in
a lot of cases, but it’s really easy
to write code that’s like? ” Subscribe to all observers observables and update the view.
” Turns out if you subscribe to only what is visible in the
page, you will get a lot of good performance improvements. This
is intuitive. While you’re writing the code,
it’s like easier to miss this, and so we have our own table component, and,
when we did this change, we noticed 50
per cent improvement, how we track these changes is
interesting. I want to show you that too. We had this internal cool tool
called PerfGate which tracks the output
of developer tools, like script time, render time, and it
records it. We have CL, like a change list,
or a commit-based tracking on that,
so if we have an improvement within we get a bug file, if
there is a regression, we get a bug filed. When we made this change to only
subscribe to things that are on the page, we saw significant
increase in efficiency of rendering and
significant decrease in memory usage. So, I want to show you – all the
internal tools, I want to show you this, because you might want
to consider having a tool like this where it
tracks your script time per CL basis, and you see it
became – it was taking five seconds and now it was taking
2.5 seconds. Those values don’t matter as much as the percentages these, like,
maybe a million rose in this benchmark. Even if you don’t
have the resources to implement a tool like this, this tool is
not what – what it does is not rocket science. It just collects the data from
the output of the Chrome developer tool performance tab.
I think that was shown yesterday. Anyways, I wanted to show this
to you. Yes, the output, when I say the
improved performance by this much percentage, I’m talking about
the value we get from the tool. So I guess the tool has the
advantage of running it in an environment,
in a controlled environment, so, it’s like if you have a developer’s tool
running that might be susceptible to other changes, other processes that are running
in your computer, so, you might want to
in vest into some infrastructure for tracking performance
degradations or improvements. Another anti-pattern we
discovered is DOM elements per cell, or DOM
elements per component that is used within a list-like
component, so this example, if you have a table component that
is attempting to write, I will just write a component that has
a DOM level, that has a DOM element that is going to
display an individual cell. This is good, but it adds DOM
nesting, and DOM nesting means Chrome has to do extra stuff. When we tried this to remove DOM
nesting, we got 15 per cent decrease in render time. So, another anti-pattern is
using listeners for element. So, if you have a tool tip, it
is tempting the Angular to write, “I want to listen to …
order.” You can add this per element. If you have a lot of
these tool tips on the page, like a tool tip per
cell in a table, that could decrease performance as well. In fact, when we convert ed –
so, why does it decrease performance? Because it misses
the fact that events bubble up, right? You can have one document-level
event listener that listens to a
mouse-over event and it will track mouse-over events for
everything on the page, and you can differentiate based on that
target. Unfortunately, this is how, it’s
like body , implementation of tool tips,
for example, listener per element. When we switch from
implementation of material tool tip to our own implementation,
we saw nine per cent drop in the script time. Interesting, React does this on
a framework level. So, like, if you have only one
event listener per event type, and everything else
is propagated through synthetic events. This might be a case
where we learn from React, I don’t know, although I assume it will come from other
problems. So another anti-pattern that we
discovered, this is rather obvious, but we missed this for some reason. If you have layout trashing
within a component that is used within
list-like components, so, again, a cell in a table, that turns
out that it’s really expensive, because that layout trash ing happens
and when you see this, it, loo like a large purple block on the performance
tab, and where you’ve fixed this layout
trashing is to find to read it at a higher level, maybe, or
don’t read it at all. Or use a third-party library
like Fast DOM to read and write, but then
bash those reads – batch those reads so you don’t change
anything in between. There’s a full list layout that
causes – in our expanding row
component, which is just a bunch of rows on a page, and, then,
when you click on one of them, it expands, and you collapse the
previous ones, it turns out we had layout trashing, and when we fixed that
at render time, it turns out 80 per cent of the render time was
just Chrome trying to recalculate the layout. So that is how we got the
improvement by removing the layout trashing in the child
component. So another Angular, I guess, anti-pattern, is using
components within list-like components that have lots of
winings in DOM. So, material check box, for
example, is a good candidate for this. It has dozens of winings. It has quite nested DOM. On the other hand, materials
check box has no template, very minimal
bindings, although, so we – we saw an
eight per cent drop in render time. But, if you do this, you kind of
lose some of the other things in that check box. Like
accessibility. So, but even if you add those
accessibility improvements, it turns out you still get pretty
good improvement, actually eight per cent. So, this is the case with a lot
of performance optimisation s where
you kind of sacrifice readability, or compactness so
that you get more efficient components. In case you didn’t know, some of
the functions like set timer, set
interval, promise, resolve, these are all wrapped in its own JS, and when these
tasks are executed, Angular runs change detection. You might not
want to run change detection. For example, if you’re just using DOM manually in this case,
if that is what you’re doing trying to use run outside of
Angular to avoid Angular change detection opinion . Batching these microtasks
turned out to be a great idea. We had seen an almost 60 per
cent improvement? Script time because in script time because in a cell
in the table, we were doing a set
time-out, a thousand cells, it means a thousand set timers,
means thousands of change-detection cycles. We bashed those by doing it on a
higher level. That might be something you want to consider
as well, to improve performance of these components. For nice scrolling without any
scroll jank, use passive event listeners. Passive event listeners are not
natively supported in Angular. If you add like a mouse field in
the right – sorry, left example, it will add an event listener
which means Chrome will wait until the event handler is
finished before scrolling, and the teen for that is that Chrome doesn’t know that it’s going to
– the elent listener cancelled the the
event listener cancelled the event or not. If you have it to true,
scrolling will be faster, but you won’t need to cancel the
scroll event, which in the majority of cases I’ve seen, you don’t
cancel scroll event at all. It’s a good improvement you might
consider doing. … change. This is rather
funny. When we need to use this, it’s
usually the case that we ruled out every
other reason, and Chrome is doing
extensive rendering stuff. Wheel change helps when it hints
the browser that something is going to change about that
element, and so the browser is able to defer some
expensive calculations. Use this sparingly, only when you need
to, only when you see the large purple block of rendering in
performance tab. But, it could – this is just one
CSS change that could dramatically improve performance
of your app. This is rather intuitive. Use visibility instead of
opacity at zero. When you do opacity zero, Chrome
still has to draw every pixel, and then it reduces the opacity
to zero. When you do visibility hidden,
what Chrome does is it just tries to
calculate the width and the height of the thing. So, just inefficient so use owe
Patty at zero. This was another inefficient
CSS. This was a surprise to us,
because – so we have, like, 50 or so front-end developers on our team, and and
none of us really knew why adding letter
spacing would decrease performance. We just find out, thanks to that
tool I was showing you, the tools just tracking ought the
changes, and it was like there’s an improvement when you removed
letter spacing, and then we actively investigated that. I contacted the Chrome team, and they’re like, “Oh, yeah, that’s
just what happens. ” It turns out Chrome does some
post-processing if you do use letter spacing. It first draws it and then tries
to insert letter spacing. And we got 15 per cent
improvement just by removing this. Also, so the reason we were
doing this in the first place is because using letter spacing was also causing
issues, in some of our integration tests, some of our
Firefox tests why flaky, I think. We got – when we investigated,
it is something the browser has to do extra. That was it. So, let’s talk more about it in
the Expert Zone. The work that I presented is not
just my work, . work. I learned from a couple of
really smart people, my co-workers, Michael,
and the other Michael. – I just can’t pronounce his
last name. Sorry! I tried really hard, but –
other, by the way, I signed up for Twitter
for you because I thought maybe, I don’t
know – I saw every other talk signing up for Twitter, like
showing their Twitter account. I was like, okay. I will do the
same. [Laughter]. Anyway, thank you! [Applause]. – Thanks, Mert. I think Mert signed up to
Twitter so he could take part in the Twitter
competition possibly. Up next we’ve got in here
creating a better culture in tech through diversity and
inclusion, and next door, we will have power and constraints.
We will start up again in about ten minutes. Thanks very much. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. – Hello, and welcome back. So, up next, just before lunch,
we thought we would have change of pace. You have had a lot of
technical talks. This is something that’s really
important, and we feel really passionate about, about the
culture that we build around tech, and to talk to you a bit
more about that are Tracey and Rob. Let’s hear it for them. – Hi, everyone! Everyone ready
for lunch? Lunch was actually pretty great
yesterday. I was surprised those little
cardboard boxes were actually hot. I had the curry. I don’t
know what you had. – Hello, everybody. Welcome to
our talk. Thank you for coming to talk
about inclusive architecture, or how we help people build
sustainable inclusive development teams through the
lens of helping junior developers using both Angular
and something we like to call the PAMstack. What is the
PAMstack? It’s a fun name we give to the
three pillars that really help to build these types of team – process,
abstractions, and mentor ship. – PAMstack is not JAMStack but when we look at
inclusive architecture enabled with Angular, what we are
talking about are a few different things. It should allow for less project
maintenance, so a codebase that’s not just reliant on a
handful of senior developers. Less stress because you have
more team buy-in, also, a more co-operative team. With code
conventions and standards put into place, then all of a
sudden, you’re not bike-shedding all the time. You can lower the
cost over time of developers because you’re not having to
spend again top dollar on senior developers because those are the
only ones that can be successful on your team. With good foundations, it means
you can hire more diverse candidates, junior developers
which creates that greater diversity on our team. – Let’s take a step back and
introduce ourselves, I’m Rob Ocel, I also
host a couple of our web casts. – My name’s Tracy, the lead as a
JavaScript consultancy. I work with Rob. We do JavaScript consulting, so
we work with a lot of enterprescribeshelping them with
their digital transformation, helping them build in-house
solutions, for example. And we are framework agnostic
too. Whatever you want to use, we’re happy to chat. I’m on the
RxJS core team. I’m a Google expert developer
for Angular, MVP, and community-related things. If you
want to get involved with community-related things and
helping women in chat, I’m happy to chat.
– She’s a tough act to follow. That’s why we do her slide
second! – Let’s talk about why juniors
are not successful on teams. A lot of the time, we say they’re
not skilled enough, et cetera, but it might not be actually for
their lack of knowledge. A lot of people perceive that,
oh, they don’t have enough experience, et cetera, but,
actually, did you ever think that this might be actually be
the fault of the teams and how it is set up? This means, if
you’re not making inclusive decisions from the get-go in your codebase, from structuring
your team, this might be the reason why juniors are failing. But these decisions actually
affect everybody – not just juniors.
– So here are some examples of things that our teams do that
actually hurt juniors. For example, we have poor
onboarding documentation. Juniors would love to answer
their own questions but if there is no documentation, they are
forced to ask questions about everything that happens. It makes them feel they don’t
belong and makes other people feel they’re being bothered with
questions. This team relies on individual excellence means seniors have to
micro manage juniors because the team was structured in a way
that didn’t let anybody make mistakes in the first place. Your code might be unnecessarily
complex, you can’t make changes without causing regressions, even if a
junior asked a senior, the ark
architects don’t really remember why the code was built that way
in the fairs place. Your team might not do reviews
or mentorship at all. This is important for junior developers
because as they progress in their career, they need that
feedback to be steered in the right direction. Without that, they stagnate and
never live up to the potential they had.
– These types of decisions don’t just hurt junior developers, and
people coming into the industry, this also helps everybody. If
you can’t onboard people really well because you have poor
onboarding documentation, that means every single person you
onboard is onboarded differently. They have different
types of information, it depends on who is actually doing it,
everything is inconsistent, and you typically have to be a
senior because you just have to jump in and just make it work. In addition to that, the idea of
individual excellence, relying on senior developers just to do
the work, that means all of a sudden you have these things
that we like to call hit by a bus fears. If you only have certain people
that understand certain pieces of the codebase, what happens if
they leave? What happens if they get hit by a bus? Complex codebases as well make
teams more unproductive. When your codebase deviates from
industry standards, then, again, it’s much more difficult for
anybody to get productive immediately. On the other hand,
if you rely on things like standards and best practices,
that means you can get productive from day one. Also,
lack of advancement. We talk about mentorship in
terms of Jewish developers, mid-level developers, but the real thing is, the
reality is, that everybody needs mentorship, right? How are you
going to grow your senior developers into architects? How are you going to grow those
architects into partners? Those are things that we don’t
typically think about. Let’s get back to the PAMstack,
and again these ideas are supposed to help you build an
inclusive team. So, we will focus on process first. A lot of you might hear the word
“process” and say oh, my goodness, what are we going to
talk about next? – But stick with us because we
think we can win you over. To start out, what I want to do is
read a quote about a team that has no process. As I’m reading
this, I want you to think about whether it describes any teams
you’ve been on in the past, or maybe your team now. You don’t
have to raise your hand afterwards! On these teams, processes are
usually ad hoc and chaotic. The organisation does not normally
provide a stable environment to support processes. Discuss in
these organisations depends on the competence and heroics of
people in the organisation and not on the use of proven
processes. These organisations are characterised by a tendency
to over commit, abandon their processes in times of crisis and
unable to repeat their successes. If you felt personally attacked
when you were reading that, just know we have tips that can help
you out and make sure that it is not true for your teams in the
future. – Lack of process basicallily
means again that only rock star
developers can can succeed. You’re rushing things. You have no idea why a – this is
like a lot of stamps-ups. Projects always go over schedule
and budget and nobody knows who is supposed to do what. Roles and responsibilities
aren’t well defined, and you have a lot of bike-shedding
which causes for a lot of stressful thinking. – If process is done correctly
and conscientiously, you can get a lot of benefits. One of those
benefits is clear expectations. As a team member, you know what
is expected of you to be successful but you also know
what you can expect of the people around you and what
they’re supposed to accomplish. You have greater team engagement
and co-operation because, again, when you know what you’re
supposed to be doing and how you’re supposed to be doing it,
then you can hold other people accountable, and they can hold
you accountable as well. You also have no single points of
failure. Again, the process takes all that information and
makes it public, so that, if one person takes a day off, or a
week off, it’s not everything falling apart as people forget
what it was that that person did. There will be less stress during
the crazy times. Before a major release is not the time to deal
with a really edge case in your process or trying to decide what
to do in a really complicated situation. When you have your
process, and you have these things decided ahead of time,
then you can go into these stressful times with comfort
knowing you’ve already planned for that. Of course, you will have reduced
conflicts and reduced power struggles. Because the process
again lays out how things are decided and what you’re going to
do, decisions don’t feel arbitrary and don’t feel they’re being
foisted upon you. – There are a ton of different
methodologies. They typically follow a very specific format.
The first thing is going to be defining the expectations. When things are calm and you’re
not stressed out, then write things down and figure out what
are we supposed to do? What is the actual plan? Then you want
to go ahead and figure out how you’re going to meet those
expectations, so, how are you going to enact the plans, step
by stem lists? Checklists, training, then you
need to verify that expectations were actually met. After you do
everything, make sure you are reviewing, not just the
code, but plans, requirements, designs, et cetera. And then also making sure you’re
actually recording the results, so what are the different
metrics that you should be looking at? After you’re doing
with that, go ahead and go back and review the accomplishments
and say what did we set out to do? Was everything we did right? And continue to go through that
process and improve your team. –
– It’s good to create the plans. You sit down as a team and stay
what are the things we need to do here? Who needs to do those
things? How should they be doing them
and when should we be doing them? You actually write these
things down and you follow them. Here’s an example of a plan, or
at least a bit of a plan, for a
code-review process. It lays out the purpose of the
process, why we do it in the first place and walks through
the steps. What I want to draw your attention to is that it
deals with all the extra situations, so, for example,
what happens in a code review if an author in a and a code reviewer disagree
on a change that should be made? Some teams might do it where the
author gets to decide, and some might do it where the reviewer
gets to decide, or teams might rely on the individual power
dynamics between the individuals to have one power over the other
one. What this process says is while
the two people should try to work it out themselves but if
they have a disagreement, at the tell the development manager,
and they make the decision. Suddenly, again, this conflict
is depersonalised. It doesn’t feel arbitrary. We know exactly
why decisions are being made. Even extra situations like can
our code reviews end if there are still issues that are
unresolved? This is not something you want
to be deciding arbitrarily in the middle of your project. You
want to know up front, and here it says, yes, it’s fine, put the
information in your bug-tracking system at the end of it and you
can close the review and move on. – So another thing I feel is
commonly overlooked is sitting down and defining your roles and
responsibilities. So here we have a simple list of people,
everybody who is participating in the code review in this
particular process, and you list down again the responsibilities
of each role with respect to the actual process, and this way,
everybody knows, hey, this is what I’m supposed to be doing,
and there is no question later on, or no hard
feelings, et cetera. Another really easy thing to do when you
think about process is just create checklists. You think
about it, right. When you’re doing things like a
code review or anything like that, you’re thinking about
different things you have to do, certain steps. Wouldn’t it be
nice if you had a checklist that you could refer to? What this is going to do is it’s
going to reduce the error-probe way of
humans – we’re all humans and make mistakes – and it’s useful
in giving it to a junior or somebody who is joining your
team. They are wondering what they need to do. All they need
to do is reference the checklist. During busy times, wouldn’t it
be nice having a piece of paper telling you that is what you’re
supposed to do so you didn’t miss anything.
– Reviews have so many positive effects, the most obvious of
which is improved quality. . it’s great to catch mistakes
before they go further on and get expensive to fix. Let’s consider this
cross-pollination of ideas. You have people who shared
approaches with their reviewer, and the reviewer shares that I
feedbacks or thoughts with the author, and this
cross-pollination idea again is really good for reviews. You
also get redundant learning. You have people looking into things
and reviewing things that they might not otherwise be familiar
with. You’re reinforcing that knowledge across your team and
again making sure if somebody is missing, that somebody else
could step in. Reduced stress and eliminating the fear of
making mistakes. It’s very stressful to be on a team when
you have to do your best work every day else your users
suffer. It’s very nice and relaxing
knowing somebody’s always going to be
checking your work to catch your mistakes. It sounds paradoxical, you think
when you’re that relaxed, you think
you will make more information thinking someone will catch
them. You make fewer mistakes because you’re not constantly on
edge worried about making mistakes.
– Another thing that you also need to make sure which I
mentioned a little bit earlier was again review all the things
very often. So, we are obviously familiar
with code reviews, but also be reviewing your meeting notes.
Check did you miss anything? Do you have any disagreements about
what you’re supposed to be doing? Designs – do you agree or
disagree? Requirements – are they the right requirements? Are
you testing the right things? Who knows, right? If you’re doing consulting like
us, email to the client. Are you on the same page? Is the
messaging the same? Did you promise something you shouldn’t
have, making sure the entire team is thinking is very
important. Then, after a while, you should be stopping and
saying, like, okay, now what do we do, right? And you’re reviving and
reiterating. Can we improve on our execution,
the processes. Should the data change? That’s enough process, and now
let’s talk about abstraction specifically with Angular. We will go through this, but the
whole idea in this specific pillar is giving you ideas of
tools and approaches that is going to help your team
achieve greater happiness, productivity, and inclusion
sievity. – Let’s start by acknowledging
that web development is hard. A lot goes into making
accessible and performant experiences for our users, so we ask our web designers –
progressive enhancement, browser come
patability, progressive web apps – the list could go on and on.
Every year, it feels like there’s more stuff to learn and this fuels
phrases like “JavaScript fatigue” or
“imposter syndrome” that’s across our industry.
– The amazing things that we have are frameworks, right? So a lot of senior developers
might say it’s easier and faster for me to
do raw DOM manipulation but you’re leaving a lot of
different people behind. I remember when I was first
learning how to code, and I was trying to build these websites
and messing around with the marquee tab, HTML, CSS, and
JavaScript, and my teacher looked at me said, okay, fine, I
will give you a framework. He did, and, all of a sudden, I
was building amazing websites that weekend. I spent the entire
weekend building amazing websites. So, the great thing about a
framework like Angular is that it lets you deal with things
like basic performance and scaleability, so imagine if you
join a really large company. A really large company has a ton
of different developers, hundreds of different teams
potentially, and where do you actually get started, right? How
do you actually start? It could take you months to figure out
what on earth is going on, how things are structured, but if
you have something like Angular in place, then all of a sudden,
you can pretty much get productive immediately, right? If they’re following the basic
code conventions and standards, you know what you’re doing, and
you can just get started from day 1. I also really love things like
Angular CLI that we have. There are tons of CLIs. I feel like it’s the rise of the
CLI these days. This is a small list of things that Angular CLI
gives you. I think the most notable again are the
out-of-the-box performance, automatic differential serving,
lazy load, tree-shaking, head-of-time compilation, that
it’s wonderful that we can migrate from in between major versions
of the library, and the fact that it is also actively
maintained, and, again, if you don’t like it, or for some
reason later on, it’s very risk for you because you can just
eject if you need to. – Another really powerful tool
for building websites that work well for junior engineers is
using things like state management. Of course in
Angular, we have really great tools for this, like NgRx,
and these systems allow us to isolate our business logic from
the presentation logic. It lets us do the really complicated
stuff in one place, and in the slightly less complicated or the
different concerns in another place. You can worry about
building semantic HTML and accessible experiences on the
one side without worrying about how that does real time
communication or any of the other various features that your
application relies on. One great analogy that I like to
use for this are the am Zion Dash
Amazon Dash buttons. Whatever the product was on the
button, it got shipped to your house. You pressed it at the
moment you realised it. What I like about this is that –
what it doesn’t tell you is how it connects to your Wi-Fi and
makes an order and decides where to send it, and how to debit
your account. All of that is obscured. You just worry about
pressing the button and the product arrives. Your senior engineers, or any of
your other engineers, can model a lot of your business logic in
this similar way, handle a – hand a lot of these
dash buttons to the UI engineers, and they can wire
them up to the UI, and you have a reasonable expectation of
success. – Another great thing about
Angular is the fact that we have TypeScript as well, and I love
this, because you know, with JavaScript, you can get carried
away with confusing little bits of code but TypeScript you’re
forced to have strongly typed methods, variables and services
and this allows you to better and much easier understand the
functionality and purpose of each part of the code. And because it’s stricter, that
also means it comes with less bugs which is way more awesome,
and I really love it because there is better error-handling
so you can easily spot the root of the problem easier, and also
in your console, you have more descriptive errors so you can
better figure out what is wrong. The great thing about this is
also, when juniors are learning on TypeScript, it makes them more conscious and
more careful in terms of designing new things and helps
to teach them best practices. – So one common mistake we see
with a lot of teams is not being more
deliberate with their user experience, right? A lot of
teams will start out every brand new project, in the first few months, building the same kind
of date pickers, modal windows they’ve built on every project
they’ve ever worked on. The teams deal with the Bob Ross
effect, where the teams will be given designs and the developers
will paint them fresh on every page with new CSS and new HTML as if there was no
other existing CSS CSS they could take advantage of. It
builds it up over time, and then everything falls apart.
– This is why we advocate so heavily for companies to be
using design systems and component libraries, and luckily
for us, we have Angular Material, one of my favourites,
and I love the fact that we just have ready-made UI
components, and you get complex things like animations out the
box, the menus, the headers, and the other great thing about
Angular Material is the team has thought a lot about the more
complex things and abstracting those things away. For example, the state of a
dialogue component is basically – you’re
provided a default already, right? There is also a lot of amazing
code samples in the documentation which I think is
extremely helpful, and also the easy global faming.
– I want to let you guys in on a secret. I’ve been obsessed with
state machines lately. I think state machines are about to
explode. They’re a powerful way for
people to isolate business logic again and code it independent of
the solutions or the syntax of the frameworks we choose to use. So, when I say that it has
exploded, I think 2020 will be a year year
for state machines because people have been talking about
them how to automate testing, build interesting games, or
minimise the amount of code that you need to use to make really
interesting changes through your UI. I think they’re starting to be
really popular, and you should be looking into them if you’re
not already. This is an example of a complex state machine that
uses the library X state. A lot of this won’t be readable,
and that is fine. I wanted to show the scale of
how things can grow. This covers the entire sign-up flow for the work shop system and it
covers edge cases like people who don’t have accounts, coupon
codes. He’s accounted for a lot of
different logic in this state machine, and he can have people
analyse it independently. When he’s done, he gets this data
output that he binds to his UI but it doesn’t matter the
solution he chooses – it with can be React, vue,
Angular, and that is powerful is that he has captured in a place
where it doesn’t matter where it is used in. If he binds it up
faithfully to his UI, then he knows things are probably
correct. – Another really amazing thing
that can help enable your team is things
like Completier, for example,. – Prettyer. You’re not having to
constantly think double quotes or single quotes, spaces or
tabs. There is a convention, and that’s it. No more conversation.
That’s really powerful. I think an – I any Nx is
amazing, and these allow to you share code and libraries between
front-end and back-end easily and reduces the amount of coding
complexity. Also documentation, right? We always talk about
documentation how important it is but I want to say it here too
again that the Angular documentation is so extensive
and so complete even to the point where there is actually an
Angular docs team and this allows you to learn core
concepts much more quickly. Also, the Angular community,
whether you’re online, Twitter – if
you’re not on Twitter, everybody’s there – or most of
us are there – or physical presence. We’ve amazing Angular meet-ups
everywhere, and these things, and this community, helps you
evolve over time. The Angular ecosystem and the
Angular team has, thankfully, actually spent a lot of time
thinking about how do we be more inclusive? They’re actually
making it part of their mission which really helps a lot for who
we are as a community. – So we’ve talked about two
pillars so far, process and abstraction,
using Angular, and let’s talk about mentorship. This creates a culture shift for
our organisations. We like to present that in a thought
expert. What it be like in your company
if there was a rule that said nobody can be promoted unless
they can nominate someone to take over their role? How might
that change the way that people in your company interact with
one another or approach their day-to-day lives. Suddenly, it’s not beneficial to
selfishly pursue your own promotions and ambitions, you
have to be keeping an eye out for the other top performers in
your company mentoring people up and helping to retain that
talent. Suddenly, the cult of the rock
star developer fades away and we have rock star mentors instead.
– I really love this. There’s so much benefit for
mentees who are involved in the process. It accelerates their learning
and growth and the – it decreases the fear of
contribution, they’re not scared any more, getting validation
that it’s okay. It increases communication skills. The more
that you can talk about your code in a good way, the better
developer you become. You also feel as a mentee more
invested and valued, and also there was a study that actually
found that mentees are five times for likely to be promoted. In addition to that, the
mentees, and how they’ve been mentored
translate on because the mentees become mentors and suddenly
you’re building this better culture within your
organisation. – Mentorship isn’t a gift that
we give to the people being mentored, it gives a lot of
value to the mentors and the companies that do this. It’s a great perk for recruiting
and obviously retention as well. It also reduces knowledge silos
and solidify your company’s culture. It’s not just the mentees that
are get promoted, mentors are more likely to be promoted as
well over those not mentoring. This is something that is good
for everybody involved – everyone in
every company should be involved in mentorship.
– You might be saying of course we know that mentorship is
important, fine, but then how do you actually practically add it
to your team? There are a few different things, right, but in
pretty much you’re basically trying to foster this culture of
teaching and sharing. So you can do the formal
one-on-one session where’s a junior and a senior might go
into the room and talk about developments. You can also do
code reviews. With code reviews, authors learn from comments on
their reviewers, and reviewers are learning new new
patterns that are potentially important to the system.
Peer-programming is amazing. This is where the senior will
say, “Write this” and the junior will be doing the coding. Tech
talks during lunch or any time. If you start giving five-minute
tech talks to your team, this inspires other people to do this
thing. If you set up a place on Slack,
for example, where developers can
share links, discuss problems and solutions, these small
little steps are helping foster a better culture for your team.
– So we’ve talked about a loft things today, but they can all
be summarised under the PAMstack. It makes it easy to remember –
process, abstraction – using tools like
Angular – and mentorship. If you’re sitting here and
you’re a junior developer and you feel I can’t make my team
dough these things, what can I do, because the stuff sounded
interesting to me? There are things you can do. You can bootstrap processes on
your team by writing down what people are doing and share that
with the people. You can volunteer and mentor
your pierce that have been onboarded. You can ask other
people questions about the project or the code, or the
process that is you’re following, and then actually
write down the answers that they give you, and put those answers
somewhere where people can find them for the next time they have
that question. You can do an and ask for code
reviews proactively saying I’ve been working on something, can
you look at it while I explain it to you and get your feedback
on it? Can you explain to me what you’re working on? I’m
interested to know what other people are working on. This will
start to create that culture of code reviews and get people
excited it. If your team loves this process, they will say I’ve
been noticing you’ve been doing a lot of code reviews recently,
that’s been useful, thanks for doing that, then ask to make
that process more solidified. Write it down and enforce it,
and it starts to become the things that your teams are doing
every day. – So hopefully, you all enjoyed
that. Also, we love to give back to
the community, and we really believe in building this
inclusive web, so we host a lot of online events, and
these are really amazing for if you’re here at AngularConnect
but maybe you travelled far to get here, if you want to be a
first-time speaker, this type of stuff is less scary, right, and
also anybody can join. These are fully recorded as well. Every first Thursday we have
Angular Online and React and vue as
well, and Ktarina is giving cloud base
training, and university scholarships. If you’re excited
about this, let us know. If you’re interested in any
Angular consulting or anything like that, we are obviously
always happy to chat, and we’re always hiring, so even if you
don’t feel qualified, it never hurts to send an email. And, you know, come and see me
and Rob after. I have stickers up here as well. Thanks for listening.
– Thank you. [Applause]. – So I think in addition to
that, I just wanted to let you know, I will also be hosting the
diversity and inclusion lunch which is happening right now.
There’s going to be lunch in the room. It’s going to be on the second
floor, so come in check it out. We will be having Robert from
Angular Girls, and Stephen Fluin giving
talks as well sponsored by Nrwl. Thanks, Nrwl. I guess that’s it.
– Thanks very much. [Applause]. So, like Tracey said, if you
want to head down for the diversity lunch, and for
everyone else, there will be a lunch break now on this floor
and downstairs as well, there will be food. See you this
afternoon. Thanks very much. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. Test.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. . – Hi, be everybody. Welcome back
from lunch. I hope you enjoyed it. How was it? All right, okay,
wow. I’m really enjoying
AngularConnect it’s been so great, so awesome. How are you
enjoying it? [Cheering]. Yeah! Okay. We have a few more sessions to
go, and I think they’re super
interesting, and I’m really looking forward for them, and
don’t forget the panel at the end of the day. But first things first, we’re
going to start with another Sli. do quiz. Another Sli.do question. Log into slido.com, enter the
code AngularConnect, and is this a very, very important
question: which Angular version are you using? So, let’s take a few seconds to
answer that. Where’s 10? Hmm! Yes, so, we’re including
AngularJS there also, okay? We have had a lot of good
things. Six per cent with AngularJS. We have had good ideas that
we’re taking from there to the new Angular, so that’s why I love Angular so
much, and I really, really happy to see that
most of you, the vast majority here, has
updated their projects to Angular 8
which is the latest current version. Some are experimenting with the
next one, version the 9. That’s really awesome. Thank you. While
you’re still on Sli.do.com, you can submit your questions to the panel tonight, so, please do
that. The panel is interactive. They will answer your very
important questions, and I’ve seen last year, for example, there were very
interesting things that were asked. All right, so before we start
the sessions, there is a very
important presenter from one of the
sponsors, Infragistics. I would like to invite Kerial
Matev to say a few words. Thank you. – Thank you. Welcome, everyone.
Thank you for making time for this session. It’s great to be
in front of you. It’s great to have met so many of you over the
last couple of days. We’ve almost run out of socks.
It would be great to see the rest of you at our booth to have
a chat. I would like to take a couple of minutes to talk about Ignite UI
and what we can do for you. We’re proud to be sponsoring
this event, be here, and stand side
by side with Google and meet so many of you. I will give a quick
introduction of who we are and what we do. As a company, we’ve
been around for 30 years now. We’ve been building UI controls
all these years. We know a lot about building
reliable, stable, performance grids, charts – you name it. Over the years, eave a lot of
expertise in making things easy to use developers. We know
developers. We’ve wondering with you for the
last – we’ve worked with you. We partnered with the major
players in the irrelevant, we’re a Microsoft partner, and a
Google partner, of course. We work with all kind of companies. We work with all kinds of
developers teams, up to your big corporate organisations with
200, 500 developers. We work across all industries. Whether
you’re building transportation kind of application, or just a
simple website to manage customers to
be for a consultancy, we can do a
lot for you. We have over one million developers. That is a
massive community that’s used our tools. We are spread across
the entire world. We can support you wherever you are. We have offices around the world
as a company that’s been around 30 years now. The product we are showing here
is Ignite UI for Angular. It’s a modern set of UI controls
that’s materials-based. We don’t just do a grid. We have 50
controls on top of that. We have charts, we have input controls,
we have layout controls, we have navigation controls. Our goal is to enable you to
take one tool kit and meet all of your
needs across an entire application range, so whether
you’re building a application with lots of data entry and
grids, or building dashboards, you can use our tool kit across
the whole solution. What is great is that it’s
material-based, so we support the material design teams out of
the box, so you don’t need to worry about different controls from different vendors,
“How is this one? How does that one work? ” You take one vendor and the
control from us with the CLI and quickly
getting up to speed on how to use them. Something we do, we have plugins
for Visual Studio code and we do a lot of the – you can configure
the grid. You don’t need to learn our API,
you don’t need to memorise any API members. You can sues the UI to scaffold
the grid like filtering, or anything like that. Without any
further ado, this is our grid. I’m sure you’ve seen lots of
grids. What’s the difference between
our grids and many of the grids out there? The big difference is
we’re material-based. Everything is customisable in
the exact way that Google wants it to be customised. That is our
advantage. We play the rules, play by the standards. We’re not trying to reinvent the
wheel or come up with a new way of doing things. We are playing
by the rules and making it easy for you to reconfigure any
aspect of this grid. Our biggest advantage as a
whole, compared to the competition in general, is
performance. So I know everyone talks about
performance, but we’ve done a lot of work around that, because
of our customer base who are some of the companies that use
the most data in the world, like financial services. We’ve done a
lot of work around virtualisation, and, on top of
that, added grouping, sorting, filtering, all the functionality
you would expect in a grid. We have a powerful Excel library,
and you can see us at the booth
outside. It would be great to meet and talk to you about your
needs. You can find us online. We are available on GitHub, the
product is free to download. You can try it out. If you want to
use it or get rich off it, you need a licence and that’s where we come in to support you and
learn about your needs. We’re on GitHub, so you can
submit any issues or questions, any concerns you have, so that makes it easy to
communicate with us. Just to show you quickly what
you can build with our tool set. That’s just one dashboard built
with our data visualisation tools. We’re not just a grid
company, we allow you to build a lot more with our charts, maps,
and gauges, and so on. On top of that, we have a great
is that right chart that you can see has a lot of
interactivity features. We fully support the zooming and
overlay functionality so you can do a lot and deliver a lot of
value to your users. You can really unlock the power of the
data that you have, because there is a lot of charts out
there, but none of them are this fast or this functional, so
definitely take a look at our product. It’s on GitHub, as I
say. It’s material-based, it’s easy
to style, easy to use, easy to customise. We at Infragistics are here for
you, just out there in the booth, come and talk to us. It
will be great to meet you. With that, my five minutes are over. Thank you very much for your
time, and we hope to see you at the booth. Thank you!
[Applause]. – Thank you very much so much
Infragistics for your support. Infragistics for your support. I
want to tell you how the I saw the name of our next speaker
online. I was researching Angular Forms
when Angular 2 was still in beta, and I was preparing a talk and an
application using the Angular forms, and it
was a bit difficult at the time. Things weren’t very in order,
and a bit confusing, so I was looking over
all the information that there was, and
then I stumped upon a design document that really set everything in place,
that said okay, this is the way that it’s done now, and it’s
confusing, and this is how we should improve at this, and all
the reasons why, and it made a lot of sense, and luckily enough,
all of this, or most of this was implemented right before I had to show the
application, and I had just enough time to work on this. And the person responsible for
this design document is Kara, and
really you made a lot of sense in that. Since then, I’ve been following
you – sorry, it sounds a bit creepy!
– You’ve been following me! – On Twitter! A real groupie! And Kara has been working lately
a lot on Ivy, the next renderer of
Angular, and she is the tech lead of the
Angular Team, so, if anyone knows how
Angular works, I bet that’s Kara? Right? Kara Erickson!
[Applause]. – Hello, everyone. Welcome to
Howe Angular Works. I guess I don’t need as much of an
introduction because I got such a great one. But I’m Kara
Erickson. I am the tech lead for Angular’s framework team, and as said, I
work day to day on the Ivy run time. I spend a lot of time thinking
about how Angular works, and that’s what we are talking about
today. So, when you’re building an application with a framework,
it can sometimes be kind of hard to imagine what the framework is
doing under the hood. But, by the end of this talk, I want you
to be able to visualise kind of how your application code and
the Angular framework code are working together. So just to jump right in. :
Angular broadly has two parts. There is the Angular compiler
which is our build-time utility, and the Angular run time, which
is the framework code that ships the application and actually
runs in the browser. Today, we’re going to focus on the run
time portion. But if you’re interested in how the compiler
works, I would highly recommend checking out Alex’s talk from
yesterday. It should be on YouTube soon and
the slides are also linked. For our purposes today, all you need
to know about the Angular compiler
is that it, in addition to downloading your TypeScript to
JavaScript, it also parses your Angular decorators and your
templates, and it generates some code that the run time can
understand. If we take a look at in
component example, we have a decorator like you would write
in your application, what the compiler would do is take
this information and it turns it into something we call a
component definition, or Don’t Def and
contains the same information and transforms into something
that the run time can actually use. One way to think about it is
that the compiler generates lease definitions and instructions, and the run time
actually implements those instruction s to run as your
application is running. Don’t worry about what is
understanding in this at this second. Throughout the course of
the talk, I will be explaining what these instructions are and
how they work. Hopefully by the end of the talk, you can read
them with confidence and happiness. So when an application
bootstraps, there are three main phases that it goes through:
there is module set-up, and this is of where the framework is
instantiating your module, setting up the module injector; there is
view creation, when we create the DOM for your entire – and instantiate
directives; and there’s change direction and changing values and updating
them if necessary. The first part is the module bootstrap
part of the application bootstrap and the second two
parts are more related to the component tree. Today, we’re
going to talk only about the component bootstrap portion
just for time purposes. So, in the course of explaining
how all this works works, we have an example that we will be
going through. It’s my cat’s personal website,
what I imagine it would look like. So it has an image of my cat on
the left. There’s an header, an info card
on the right that has all his information, and there’s a
Twitter component that actually scrolls beneath this
view port with his contact information. That’s the app that we maybe
using. The code might look something
like this: an app module, a few
components, one for the root component, a –
and then in the root component template, you can see some of
the things that I just showed you. There’s the image of the
cat, the header, there’s info card. So, when we bootstrap this
application, we’re going to start with
whatever component you put in the bootstrap property of your
NgModule. So the framework will start
looking at app component. There are a few special things that we have to do at the very beginning
to set up your root component. First thing that we need to do
is locate your root element. When you wrote your index at
HTML, you added some tag, right, like “app
root” and it should match whatever selector you have in
your root component. So the framework needs to figure
out where this element is so it can
bootstrap your application inside it and append the
elements to it. When you compile this component,
the selector gets compiled into the definition, so we still have
that information, so the framework just takes this selector from your
component definition, and document.
queryselector, and that’s how we can locate the element, and
that’s pretty straightforward. Next, we want to create an
instance of your root component. Again, this is something that
the component definition makes pretty simple. The compiler
generates a factory function that tells us how to correctly
create this component with any dependencies that I may have. So, in this case, there are no
dependencies, so it is straightforward. We call the factory function to
get that started. Then we’re actually ready to
start rendering the root component. This is where it gets
interesting. So view creation, starting the
process of creating the DOM and
instantiating directives. This is where the template function
comes in. You will recall that your HTML
template is turned into a function. All the framework needs to do is
invoke this template function and give it a particular mode,
so in this case, creation mode. As soon as that function is
invideoed, it will create the DOM correctly for that
component. oked, it will create the DOM
correctly for that component. If you imagine this and the as
the component tree, we can invoke the template function in
creation mode to create the app component, and
then we can invoke the … if we want to
unit an entire application, for the DOM, for an entire
application, all we have to do is call all these template
functions in our component tree. What is the template function?
The template function is a function that is composed of a
number of instructions. And with when I say
“instruction, what I mean is it is like an Angular
– it’s a function that is implemented by the Angular
framework that does some specialised piece of work. You can roughly divide them into
two camps. There is creation instructions,
which you may have guessed they create things, and usually it’s
indicated by the name, so the element instruction creates an
element, text instruction creates text node, the
projection instruction creates ng content. You can guess where
this is going. And the update instructions will
take an existing element, or component, or something, and it
will update it. So the property instruction updates a property,
the attribute instruction updates an attribute. Once
again, it’s pretty self-explanatory in the name. What instructions are actually
generated in your template function depend on what you’ve
actually put in your HTML template that you have written. So, if we go to the app
component’s template, the compiler would generate
something like this, this equivalent template function.
Right now, we are focused on the top part, right, because we’re
in creation mode, so let’s start by explaining how all of this
works. So the first thing I want to
draw your attention to is that the structure of your template
function it is really mirroring the structure of your HTML
template. You see we have the image tag on
the right, the source attribute, and then in the element
instruction, parsing in that tag name, parsing in the source
attribute, so they’re really similar, and we do that on
purpose so that it is easy for us to create the exact DOM that
you wrote in your template. We’re not just actually taking
the template strength, that HTML, we’re not HTML-ing it, we’re creating all
of the elements one by one which is what the instructions do. If
we take a closer look at the element instruction, we would
take the tag name that you give us, and we use
really recognisable DOM APIs that you have probably used
before like document.create. element, pass in the tag name,
get whatever parent is the right one for right now, which would
be the root element in this case, set any
attributes we set, and then just append the element we’ve created
to its patient. So, much more straightforward
than you might expect. We also do one more thing, and
that is we track all of the elements as we are creating
them, so we store them in our own internal data array, and the
reason that we do this is because, later in change
detection, we’re going to be updating these elements, right? And so we’re going to need some
way to get access to them. We could use query selector to
get hold of them but that could be
expensive and flow so we have our own way of keeping track of
these elements so it’s fast for us to acset them later. The
internal data array where we store the elements is something called
an L view, also known as a logical view. We create an L view instance for
every template instance, or every component instance. Every component has its own set
of storage that has its DOM elements inside it. So in
addition to DOM elements, we also put things like binding
values in here so we can check old binding values against new
binding values. We also put directives instances in here so
we can set inpuss on them later. Every component has its own ts on them later. Every
component has its own … we’re going through and adding each
component in the array. If you go back to the template and
imagine that we are executing it line-by-line, we will create
this image tag, away append it in the
correct place and store it here. We will create the H1, append
it, do the same for the info card and the footer. There is one more thing that
these element – really just element instructions are doing,
and that is directive matching. So, at compile time, the
compiler will analyse your NgModules and your
component decorator and figure out based on your NgModules what
directives are available to your component and its not awed
scope. Once it knows what the directives are, it will print
out that list of directives inside the component definition.
Here for the app component, it has access to the info card
directive components and the footer component. And this makes it much easier
for us, because at runtime, the runtime doesn’t have to worry
about module scope or any of that stuff. We know what our list of
available directives is. So the registry up here on the
right, so you can kind of visual cries it. As we are creating all of these
elements, we are matching directives against the elements that we are
creating. For the image tag, we look at
the image tag. We grab its definition, look at
its selector, right? We try to see if the image tag matches the
image card selector. If they don’t match, we will keep
looking, checking to see if the image tag matches the footer
select. Still won’t match. We keep going through as we are
creating until we actually get a match. At this point, we need to
actually instantiate the component that we found. So your
first thought might be oh, you know, the framework should just
call new on whatever type it is and then you’re done. But that
doesn’t really take into account dependency injection. Any of these components or
directives could have any number of parameters that could be
anywhere in the tree, and so what we do is we instead call
the components factory, and this is the same factory function
that we invoked at the very beginning. So, if we look at what info
cards factory cards factory function
will look like, it will call new on info cards like you might
expect but it has this directive inject instruction. This is the instruction that
powers dependency injection. This is the thing that is going
to get this info token that you have asked for. Dependency injection is kind of
its own talk, but the gist of it is that
it will take the token and first check
the directive injector tree. The directive injector is where
we keep track of all of those providers that you added on
directive definitions and component definitions as well as
the directives and components themselves. So every time you have a node
that has directives on it, we create a directive injector. So it becomes this big tree of
directive injectors as you walk up the digital. We look at the
directive injector for the node that is closer to where we are
requesting it and keep walking all the way up to root. If it is not there, then we fall
back to the module injector. Module injector is where we keep
track of providers that you set on ng
modules. If we don’t find it in the
module injector, you’re out of luck. Furthest info service provider
in our example app. Let’s say we provided it on the app module. So, when we’re creating the info
card, we call directive injects, and directive inject will first
check the node that we are currently on, so it will check
the info card node. They will try to see is there a
injector directive here? Is there a director inject – then we move
up to the next parent element that has a directive injector
which will be the app root element which the app component
is on, so the app component
provides info service? No, it didn’t. That’s when we take a look back
to the module injector. Has it been provided? It has. We’re
happy. We can correctly create the info
card directive with the info card service. So as soon as we create the info
card instance, we’re going to want to save it? In that same L
view array. Like I mentioned earlier, we need to keep track
of directive instances so we can set instances on them later
and create hooks with the contexts. There are a lot of
things that we do with directives. You need to keep
track of them. Then you can create multiple
directives on the same node and check the rest in the registry
after that. Match the footer later, and, you
know … add it to the same array. , add it to the same array. You might think this is super
expensive, your directive registry is more than two – it’s mostly
common module, you might have material, and that’s very true. And so directive matching is not
something we want to do more than once per component. We want
to do it the very first time we see a component and then never
do it again. How do we make that work? Essentially you make that
work through shared data structures. I’ve already mentioned the L
view and how we create one per component
instance. We have a T view, or a template view, and we create one
of these per template function, per component type,
however you want to think about it. For example, if you have a
component that has ten instances, you would create ten
L views and one T view, and all of the instances would share the
T view. The way we make this work is we
store the T view on the component def,
so the next time we create the component instance, we can look
at the dev and look at the what we stored the first time around
and make use of that. In practice, it may be Geneva our elements in L view, our directed
instances, and as we are pushing directive instances into the L
view, we are pushing their definitions
into the T view at the same index. Similarly, as we are creating
DOM elements, we’re also pushing template nodes into the T view at the
same index and template nodes, or T nodes,
are essentially metadata about each DOM element, so it will
have information about the tag name, or
information about directive matching. On the T node there will be a
list of directive indices that match this node. For info card, for example, for
the second time we go through the app component template, we
go to the element, we check if there is a T showed that we
already created. The T node will have the
directives stored for the node, we can point to the definition
and go ahead and instantiate it immediately without doing any
matching. It makes it really quick for
subsequent component … so, that pretty much takes us
through view creation for a single component, but we
mentioned we’re going to do this for every single component. It brings us to change
detection. Change detection again is the
process where we check all of our binding values, and, if
they’ve changed, we render the view to reflect the updated
values. It’s very similar to view
creation in that we can go ahead and invoke the template
functions down the component tree, but instead of using the
creation flag, this time, we can use the update flag. If you call these template
functions top to bottom, that’s change detection essentially. Now we are going to focus on
this second half of the template function now I’ve explained the
first half. This is what will execute when
you’re in update mode. So, again, the first thing I
want to draw attention to is how similar
these two things are. You have your template on the
right and your template function on the left. There’s the header binding – you
can see that in both places – and below that there is the name
binding. You can see them. However, we’re no longer
creating elements, right? So we’re not necessarily going to
have a one-to-one mapping for every element. There will be some elements that
have multiple bindings, some elements that have no bindings,
so to keep track of which element we’re on when we’re
generating our binding instructions, we also have these
advanced instructions. These kind of tell us how to
negotiate between nodes and bindings. So this is much easier to
visualise if you kind of can see the data structures. On the
right here, imagine this is the LView, the array we’ve been
storing our elements, and these 0 through 6
are the indexes or indices of the LView. We’re going to need to keep
track of two things: one is the current node – so this is the
node that we are currently on, the node that we actually want
to update the properties for; and then there’s the current
binding. The current binding keeps track
of where we are in the LView. So, basically, we need to keep
track of all of the old values of
bindings that every time you run change detection, you can tell
whether it’s changed, right? The old binding values we will
save in this section of the array after the DOM elements. So, we will have the counter
that keeps track of where we are in that section as well, and you
will see how that works in a second. Okay, so let’s say we execute
the first advance instruction. All this does is tell us that
the first binding is two nodes down, so it
will say increment the current node counter until you get to
the node that is two nodes below wherever I am. So now we’re on
the text node. We run the text interpolate
instruction. And all this does basically is that it checks the
header variable that you passed in, so contexts that
header against whatever value you have at the current binding
index, which is right now, it’s simplity. So the – it’s empty.
We assume that the values have changed. We are going to go ahead and
update that text binding in the DOM, and we also cache the value
for the next time that you run change detection. Then we will increment it so we
don’t keep overwriting the same value. We’re done with bindings on the
current node. We advance one, and that tells the framework
that the next binding is on a node one slot down. It takes us
to the info card. And then we execute the property
binding instruction, and that says for whatever node you’re on
right now, you want to check the name property, and, you know,
use the value that I’m passing it, the name value. Again website it is the first
time, we assume it’s changed. We want to update the binding slam
here. You notice that this is a
directive input, right? This is not an element. We don’t want to
go and set the name property on the element. We want to set it
on the info card component. But you will remember that we have
this beautiful mapping between this
certain node and all the directives on the node, so it’s
pretty simple for us to extrapolate which component this
is and set the inputs on it directly from there. So the next time you go through
change detection we will be checking
lieu the through the values that you saved, and whatever the value of the name
is, checking against … . So one thing you might have noticed
is that change detection is going to be running within a
view from top to bottom, right? We are keeping the ordering as
we mirror the template. The component tree is checked
from top to bottom, and all the nodes
within a component view are also checked from top to bottom. It’s
pretty predictable. If you had the template with the detective, the one, two, three,
four,iv, the one, two, three, four, you can secretary that it
will be executed in the order that you see – 1, 2,
3, 4 – in the order that you set. Before Ivy, this was
different. I no, I don’t don’t know you guys can guess what the
order would be right now? Think about it in your head. Okay. Is
this what you thought? 3, 4, 1, 2? The reason for this is that
pre-Ivy, we would do separate passes: one full pass for
directive inputs and another full pass for element and text
bindings. So, in practice, it makes sense
from an implementation standpoint, but from a user
perspective, that is super confusing, right? You wouldn’t
expect it to happen in a different order that you see. That’s one thing that we have is
we make it more predictable how your template’s going to run and
be checked. But one thing I want to call out
is is that while we would guarantee the binding order
between nodes, we don’t guarantee binding order within a
particular node, and there is a really good reason for this, and
it is essentially to reserve the right
to optimise bindings within a node. So, for example, let’s say
we have this component, it has a bunch of property bindings and a
bunch of attribute bindings, we could just generate something
like this in your template function where we have an
instruction for every binding in the same
order that you wrote it, like you might expect. It’s pretty duplicative. You have two property
instructions, two attribute instructions. Is there a way we
can optimise this? You can using property chaining. If we fudge
the order a little bit within a node, we can take the property
binding from below, and we can chain it on the property binding
at the top, and we can do this because the property instruction
returns itself, so the function is returning an instance of
itself, so we can keep chaining properties and attributes and
save those extra function s names. This might seem like a micro
optimisation, and it is, but it makes a big difference over a
large template. This is the takeaway thing we like to do. One thing I haven’t talked about
is hooks. They actually execute as part of changette ex. I
omitted it for simplicity. I’m going to go back and enrich
what we had before. So, you are probably familiar
with bicycle hooks, but I will do a quick review. The first three, these are all
hooks that have to run after the input are set for a particular
directive. After view checks – it happens
after the view checked. And then after content checks,
it happens after content children are checked. But what you may not know is
that they actually execute slightly differently, so these
first three hooks, we execute node by node, so we will run
them like one node at a time. Whereas the other ones we run
view by view, so run them at once for review rather than all
at once for a particular node. That means that all of the node
by node ones that are change, Init, and
Check we have to run when we run the template function. That’s when we’re evaluate ing
the nodes. If we go back through this process, all the hooks are being hooked in in
advanced instruction. In addition to changing the
cursor for the current node, we are also
executing life cycle hooks. Here, as soon as the advance
instruction runs, we know that we are done with all of the
inputs and the winings that are that node, right? That’s how we
know we can advance. In this one, we say there are no
more bindings for node zero and node one, so we can execute all
the life cycle hooks for node zero and one. Move the cursor like we did
before. Check the binding for the text
binding. Update the value like we did before. And then we get
to the next advanced instruction, and, at this point,
we’re done with all the bindings in the text node. Obviously, this doesn’t work,
we’re not going to have life cycle hooks for the text node.
If this had been a normal element, this is where we would flush any life
cycle hooks for that node. Let me check the last
instruction. At the end, there is no more
advanced instructions because we’re done, right? After the template function is
invoked, we scrutiny of the life cycle hooks that remain for
things that don’t have bindings. So, after the template function
runs, we actually do a few more things. One thing is that we
refresh your embedded views. These are all of your ng
templates that have been add ed NgF or *ngFor. Then we flush the content hooks.
They happen view by view. This is where we flush all the
content hooks at once for a particular view. We set host bindings. Once
again, we are calling it a template function for any of the
child points in the tree, and afterwards, it’s when we flush
all of the view hooks. View hooks are bottom-up. We
have to check the child components first. Hopefully by
now, you have a better understanding of what you’re
seeing here. We have gone through all the instructions.
Hopefully, this isn’t as scary. Just as like a quick review.what
we’ve seen. In view creation, we created some elements within set
up attributes. We didn’t have any listeners,
but that’s where we would have registered them. We inbe stanciated directives, –
instantiated directives. We called life cycle hooks,
checked checked the bindings and our child components.
There’s a lot going on. But hopefully, that’s a little
bit more digestible than it was before. Thanks! [Applause]. stantiated directives. We called
life cycle hooks, checked checked the bindings and our
child components. There’s a lot going on. But hopefully, that’s
a little bit more digestible than it was before. Thanks!
[Applause]. – Thank you so much, Kara. I would like to remind you to
submit your connections at slido. com and asked a specific
question about refreshing embedded views, right? That’s a
great opportunity to hear about that. – Let’s take half a minute for
everybody to sit down. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. . – I see people still coming in.
Let’s give you just a little bit more time. Can you move up so there are no
spaces in the middle? It will be easier for people to find a
seat. Everybody has some spare seats
in the middle of the row. Please move a little bit so it
will be easier to sit next to you. Okay. Our next speaker is mike Ryan. – Mike Ryan. He’s a Google
Developer Expert, and he works at Sinaps. He’s a software engineer there,
and he’s also a core team member of
NgRx, and he’s going to tell you all about it. Thank you, Mike. [Applause].
– So I want to start off by telling you one of the reasons I
love similar is because it’s so easy to use
radioactive reactive programming concepts inside my components. I want to improve that
experience for developers because many of you like me have run into problems when we
try to do this in our components. For example, let’s
say we’ve got this template here and I’m using a observable
directly in my template with the async pipe. Everything looks
great until I jump to the definition of this component and
I realise that the observable they’re using is actually one
coming from the HTTP client. Okay, but, here’s the problem:
when I look at that template again,
sometimes subscribing to it twice, the request fires off
device. A bit of a gotcha. I point this out, we refactor
the code, and think of a new way to bring it into our template,
and you start to see syntax like this where I’m going to use
NgRx, not using it to control an element, but use it to unpack
that value out of the observable and use it as a template
variable. This makes it a little bit easier to use, and I no longer have
multiple subscriptions running, but it gets a little messy if I
want to use more than one observable. You start to nest
it, and nest it, and it gets a little chaotic. That’s not a great approach,
either. Another strategy we can take is
go back to the component definition and instead of using a observable directly
in the template, we can subscribe to that observable and
take that value and store it as a property on the component
instance. But you may have already noticed
there is a but, here. By not cleaning up the subscription,
I’ve got a memory leak. I need to go back in, refactor
the code, make sure that I’m
undescribing from it from the life cycle hook. When I got it all working in
terms of making it easy in the template, I run the application
and something crashes, and I end up with stack traces
like this that are ridiculously long, making it harder to debug
what is going on. I want to know: can we provide a
better experience for reactive programmers trying to author
Angular components? I want you to help me build this. I want you to help me solve this
as if we were all open source authors trying to launch a new
library. My name seis Mike Ryan. I’m a software engineer at an IoT
company, and I’m also one of the co-creators of the NgRx project,
a collection of open source libraries trying to bring
reactivity to the Angular framework. My goals for improving
reactivity in Angular are this: I want to make it so that
developers can use observable values easily in their template. But I also don’t want them to
have any accidental memory leaks. I don’t want developers
to have to think about managing subscriptions. And I kind of want to give
developers the opportunity to build Angular
applications out zone.js. When I started to build an open source
library, I’m a big top-down designer. I like to think about what would
my users want to use? What would be a good experience for them? So, so sort of share some of my
ideas about this API, I have to talk briefly about how change
detection works. When you’ve got a tree of
Angular components that comprise your application and something
interesting happens in them, one of those components might become
something called dirty which means it needs to be updated.
Angular will go through this free of components from the top
down and it’s going to find any components that are dirty and
actually update those views for us. Where do zones come into
play with this? Interestingly, zones don’t have
much to do with the change detection mechanism itself.
Zones tell Angular when to run change detection. Zones are going to pass of the
asynchronous APIs on the browser, and when your code
reacts with the APIs, that will cause change detection to be
triggered. It has the potential trade-off. First, it can potentially one
change detection too often. If you’re using a particularly
noisy asynchronous API, like a WebSocket connection, you might
incur a penalty because zones don’t know that
not every asynchronous operation needs to cause change detection
to run. They also have the potential trade-off where it
might cause change detection to be skipped, so, if we’re using a
particularly obscure browser API that zones haven’t actually
patched, then you might be caught in a situation where your
UI is not updating. So, open source designers, how
can we go about trying to fix this? I want to challenge you really
to think and look around other ecosystems. As Angular developers, it can be
easy to look , our own ecosystem and try to figure out how to
solve this within those walls, but I want to look at other
frameworks and technologies that are trying to achieve some of
these problems. I’m going to do something kind of taboo: I’m going to put some
React code on the screen and walk through React for a second.
It solves it in a interesting way. In React, you have this
idea of component-level state – the values that change. When that state changes, you
view gets updated. As the author of a React
component, you tell React exactly when that data updates. What’s really interesting about
this is that is how React knows when to run its own change
detection because the developer has told it that the underlying
data has been updated. There’s some pretty interesting benefits
to this approach. First, changes to state are what
causes change detection to run, not asynchronous operations. This means that the developer
has full control over when change detection actually runs
because they have control over state changes. This can make it a little easier
to keep the UI consistent and up to
date in a performance-sensitive way. That’s a pretty interesting
approach, but if we were to try to do this in similar, we would
have to overcome the problem that Angular doesn’t have
component will be -level state. We don’t have a built-in
low-level state mechanism for Angular components. Actually, make we do. If you’re using something as
simple and elegant as a subject with a service or something more
complex like NgRx, then like as an Angular developers
you’re tracking state with observables. Observables are the mechanism by
which we track changes to our data. If I wanted to design a
way to do this better at the component level, I kind of want
to borrow from both. Let’s imagine we had a hook in
Angular to handle our change detection and our components for
us, whereas component authors would say this is the kind of
state that this component has and we can call on it some kind
of connect hook or pass on a dictionary of
observables that will subscribe to those observables and update
our components for us. Then from there, we could take
that state and use it inside of our templates without having to
wait for the asynch pipe or multiple subscriptions. How can
we go about actually building this? First, we’re going to need
a demo app. As an open source library developer like yourself,
you’re going to need something to actually tinker with and play
around with. I want this demo app to actually
use Ivy, because there’s a few interesting things that Ivy’s
going to give us when we actually go to try and build
this. First, Ivy’s going to enable us
to build something called Higher Order Components. We will get
into those in a minute but the idea that we build inject
customer behaviour into our customer components. Ivy also has new change
detection APIs that will make it a little bit easier to work
without zone.js, and since we’re talking about binding states
into our template, it will be really great that Ivy
gives us improved type safety in our template. Let me show you the example app
that I’ve built dozen s of times. It is a impcounter. You
can add a number to it or subtract a number to it. It’s a helpful demo app because
it demonstrates two things: state and changes to state. You can author it inside of a
single Angular component. This is how I’ve built my example
app. I have two buttons that push
values into a subject, either a negative one or a positive one, depending on
which button you’ve pressed, and then I’m going to take that
stream of values and use the scan operator to add
that value to my starting number. If I add a one, it will
increment. If I put in a negative one, it
with decrememnt. How do I turn on Ivy? All I need to do is run the ng
update command passing in the next tag
for both Angular core and Angular CLI. This will update me
to the earlier versions of Angular 9 where Ivy is turned on
by default. That’s all I have to do. To turn off zones, I have to do
a few more things. First, I need to go into my
polyfills file and need to common it out. I need to go into my main .ts
file and let Angular know that I’m not going to be using zones
in this application. Once I’ve done that, we can see
the application has booted up, but, when the user interacts
with it, nothing is happening. This makes sense, since we
haven’t included zones any more, there’s nothing telling Angular
when to run change detection. So that brings us to the first
bit of IV API that we are going to use. We’re going to use new change
detection that comes with Ivy to try to trigger this. Traditionally, if we wanted to
run change detection manually in our applications, we would run
the change detector ref and call the changes on it. There are a
few downsides to this. First, we had to inject it into the
component that wanted to use it which means if we wanted to
build functions or libraries to run change detection for us, the
component would have to inject itself and pass it to the
library. It also had the downside where
it might potentially cause the change
detention ex-to run multiple times, maybe
a – in Ivy, it gets a lot simpler. There is a nudges called Mark
Dirty where you pass in an instance of a component to run
change detection on it. I don’t need to inject into the
component, and it’s got some interesting properties beneath
the hood. To play with it, we can open up
the console in our Chrome Developer
Tools, and get at the component instance. From there, I can call
some method on that component instance to cause state to
change, and then I can use the ng probe to mark that component
instance as dirty which will cause change detection to run.
If we are going to build our library on top of this, we need
to understand what it is doing underneath the hood so we avoid
any potential gotchas. What does mark dirty really do? How does
it work in an Ivy application? The function signature is pretty
simple: we’re just going to pass in an instance of the component. Then Angular’s going to do
something called, it’s going to get that component view for that
instance. Now, this component view data
has enough information in it for Angular to go ahead and mark that view as
dirty, meaning when change detection runs, this component
will be checked and its bindings will be updated. Mark view dirty returns
something called the root view. Root view
is pointing to the top of of that tree, the top of that tree
element. From there, mark dirt iiY will schedule
schedule tick. What is root context? Root context has information
about how our Angular application is meant to run. For
change detection, there are two parts that we want to pay
tension to. The first is a scheduler function. It’s going
to be responsible for making sure that some amount of work
happens after everyone has scheduled work to be done. The
second is the flags. Flags tells the root context
what work will be done when the scheduler fires. So, if we go back to our
schedule tick, we can start to unpack what this is doing a
little bit. By passing in the root context and a root context
flag, it’s instructing Angular that you need to do some work at
some point in the future, and the work you need to do
specifically is you need to detect changes on the Angular
application. And this means that this
function can be called safely multiple times without causing
change detection run at multiple times. Now that we know how to use it,
we can use it inside our components. So, if we go to our component’s definition, first import mark
dirt iiY. Mark dirty is not a stable API. We should not build production
software on top of it. With this demo, we can play with
a little bit using the “import as”
as syntax. I can call the tap operator to
markDirty on this component. If I run my app, things are
working. I’ve got Ivy, I doesn’t have
zone.js but my application is updating live. I know if I ask my team to call
mardDirty, including myself, we will forget to do it sometimes.
I want some other piece of code to be responsible for calling
this for me. That’s where higher cord
components come in. This is something interesting about
them. I don’t know how as a community we’re going to build
higher order components yet. This idea is so early of
bringing higher order components in
Angular that it can be built with inheritance or functions. For this, we will build them
with inheritance. We will change the way they run,
render, or how change detection works. What is great about them, is
they can call new Ivy APIs like markDirty
on my behalf. I can build this using a
higher-order component. I’m going to create a class that
everyone will extend if they get to behaviour. When you extend it you get
access to a member method called connect that you can pass that dictionary
observables to and will cause it to update live. This is how our API is going to
work on an Angular app but how do we actually build this? That
doesn’t seem particularly clear how we build this connect
method. So, apairing open source library
author, let me tell you, if you’re going to publish an open
source library for Angular and don’t get the types right, you
will have nothing but issues for shears. It seems our developers
like it when the libraries are well typed and they don’t have
to work around with the definitions that come with your
library. If we want to get the types
right, we need to leverage inference. 8 This is what the user is going
to provide to us: they’re going to provide us with an interface
that matches something like this, and we need to be able to
infer using a special type the result that looks like this. To do that, we can use a type
alias. Here I’ve created one called
observable dictionary, and it will be using TypeScript’s match
types feature to do this inference for us. This is a complex type, so let’s
break it down piece by piece. If we start with the symptomatology
state definition, we’re going to first use the “key of ” operator to get every
key in that input type. Then we will iterate over each
of these property names to map into a new object type. From there, we could index the
original type to get that original value, so now we’ve
rebuilt that original value up, and now we can nest it inside
the generic parameter of the observable type to get from the
original type to the inferred one for the dictionary. That
gives us our types all in place. Everything will infer correctly.
Now we need to implement this connect method. We will start by creating what
I’m going to call a sync. As we subscribe to values, we
are going to dump them inside of this sink. To get at those values, first,
we have to enumerate over all of the keys inside of the
dictionary. I’m going to build an observable
from these keys and take every one of these keys, and I’m going
to look up that original observable that the user passed
in. When that observable updates,
I’m going to write that new value to my sink. It’s running. I’m going to
subscribe to the observable I built up. When any value changes I will
call markDirty which will call change
detection on my Angular. Let’s say you pass in a
dictionary which looks like this where I’ve got an observable of
vegetables. What this will do is it’s going
to subscribe to that observable, and whenever a value changes,
it’s going to update that value inside of my sink allowing me to
use that value inside of my template. So now that we have an
implementation, we can go back to our component, and we can now
go back and remove the im port to markDirty and immediately
order the higher component. Now we have access to the state
values and the subscriptions are being managed for us. So we can go back to our
template now, we can rip out the async pipe and use state.count
directly. Everything is looking really great. But I go on the application, and
something’s broken. What’s gone wrong? So I open up my console, and
I’ve got this really long error, and it’s something like cannot read
property node undefined, and I don’t know what that means. When
I look at the second line, I see something familiar: get
component view by instance. Hey, I remember when calling
that in markDirty. Angular calls this as part of
the change detection. What is this really doing? The way Ivy kind of works at a
very high level is that it’s going to first instantiate an
instance of our component, then it’s going to create our
component view for us, and then it will call our life cycle
hook. So, if we can look at the definition for that connect
method again, the problem happens to be at this line. We are calling markDirty on the instance of our component before
the component’s actually been initialised. So, we need to use life cycle
hooks in our higher order component. How do we do this? How can a higher-order component
get access to life cycle hooks? It turns out, it’s fairly
straightforward. All we have to do is implement the life cycle
hook and Angular will call it for us. I don’t want this in the format
of a callback which I want to turn this into an observable so
I can compose this in my stream and offer life cycle
hooks to anyone who is using this higher order component. I’m going to do that by
initialising a subject, and I’m going to next a value into it
when it gets called. I will mark the subject as
complete to let any subscriber know that life cycle hook has
been called and won’t be called again. But, library author, let me tell
you that, if you expose something like that been your
users will it. So we need to hide some of the implementation
details. To do that, I’m going to hide
some of these properties behind symbols. That way, consumers of this
component can’t get at these properties other than beyond the
observable. I’m going to do the same for ng
– so what I’m going to as on is
I’m going to use the concat observable
factory and I’m going to pass in on Init
first and then update sink. This will ensure that OnInit has
run and completed before I try to update my sink values. Then I will use the operator on
it and pass in tea the onDestroy life
cycle hook which means the subscription will be cleaned up
for me when the component is destroyed. Finally, I’m going to subscribe
to this observable and mark the instance as dirty. So if I run my flicks and I hit
either of the buttons, values are updating live. I’ve got
change detection running for me automatically. I don’t have to use the async
pipe in my template. Subscriptions are guaranteed not
to leak because the higher order component is managing those for
me. If I do something more complex,
like I’m using subjects with the service, then I can leverage this higher
order component to connect to that state management offering. Or if I’m using NgRx, I can
tree-shake those can take those observables. Libraries like NgRx and others
can take this idea one step further and they could offer
their own higher-order components that remove a ton of
boilerplate that we have to write when connecting up our
components to state-management solutions. So now that we’ve built reactive
component, we’ve achieved goals we set out to do. Developers using reactive
component can use values without the async pipe. It’s easier than ever not to
leak memory accidentally because we’re no longer responsible for
managing subscriptions, and this makes it possible to build
entire Angular applications without zones by leveraging the idea that all of us use
observables to track state changes. So maybe you’re wondering how
can I use React component? Can I run out and use it now? The
answer is, unfortunately, no, because, like I said at the
beginning, I need your help to build this. I’m really excited to announce a
new initiative on the NgRx team called NgRx Component. It’s a library coming directly
from the NgRx team to make building
Reactive components easier than ever. It’s early days, but the
idea to build this on top of the some of the new APIs coming out
with Ivy, and we want you to get involved in helping us make this
library really fantastic. To jump-start you, here’s a link
to the slides along with all the code demos I’ve shown in this
deck. You can run this application
live and start playing with this idea now. Thank you. [Applause]. – Thank you so much, Mike! Wow. These are great ideas, and I
hope you implement them, and this is your opportunity to help the
community and contribute to open source projects. We have a few more minutes
before the next talk. So, in the meantime, you’re
again reminded to submit your
questions to the panel in slido.com. Log in with AngularConnect, and
your connections will be asked in the panel. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. . – Okay! How are you all doing!
Yeah! AngularConnect! Oh, my God. This
is I think one of the last sessions, right? And this day has been going so
great, and so much wonderful content,
and we’ve learned a lot of things. I want to remind you
once again to submit your questions to the panel through
slido.com. Everything that you’re asking there is going to be considered to be
asked to the panel. But we had some great questions
last time, last year, some
interesting things, new point of views, so please to this. We
want to hear you. Our next speaker is Sam Julien,
zBand he’s developer-advocate and also for
the five per cent of you who are
still using AngularJS, he’s the creator of
the course Upgrading AngularJS.com.
In his free tile, he enjoys also hiking and camping, especially
in Portland, where he also runs the Angular community there. So, please give a hand to Sam
Julien. me, he enjoys also hiking and
camping, especially in Portland, where he also runs the Angular
community there. So, please give a hand to Sam Julien. – [Applause].
– Am I on? Can you hear me? Awesome! Last session of the
day! I think they put me on for entertainment. I’m not quite Sonny levels of
entertaining but I will try to keep you happy in the last
session. Hopefully, you’ve gotten a deep breath after all
the Ivy stuff you learned. We are going to talk about facades
today. Facades can be a little
controversial. You might have heard different people talking
about them, whizzing around the community. Some people love facades. Frosty, who wasn’t here today,
he loves facades. He thinks it’s a pain to have to inject a store
into a component. Symptom people, like a certain someone in the front row who gave a
talk, are let keen on facades, a little more sceptical on them.
I’m sure there’s a churching of you out there sitting and
thinking what the heck is a facade? What is this word that you keep
saying? I’m going to go through what a
facades are, what the pros and cons are, and whether you should
use they will. I’m Sam Julien. You can follow me on Twitter. I’m a developer advocate
engineer which is a fancy word for developer relations. I’m a GDE and an Angular
collaborator. I created upgradingangulajs.com. I’m about to come up with a site
on Gatsby that uses [whispers]
React! We provide an authentication
service for developers. It’s simple but ens tensible and
it has a real focus on the developer experience. I live on
a small organic farm. These are my 19 chickens. And these are my two llamas,
Michelle and Barry O’Llama! That’s Barry over there. Barry’s on the left. If you
follow me on Twitter, you will get a lot of chicken and llama
content. That’s the good stuff. So, first and foremost, what the
heck is a facade. What do I even mean when I talk about a facade? This is a very famous facade in
your neck of the woods, Buckingham Palace. There’s another famous facade in
your area, 23 be 23Leinster Gardens.
The building on the left is real. On the right, it’s fake. It’s actually railroad tracks
running through it. This is a type of facade. This is a facade
in the way that we think of Instagram being a
informed, right? People post these beautiful
pictures – thank you! Thank you. I wish I had created this
picture, but, yes. So this is a type of facade,
when we use it in like common parlnance,
it hides away the messy things. That’s what we kind of mean.
When we talk about codes, we mean the relationship with your
car. When you get into your car, and
you use your gear shift, and your drive
peddles, you don’t have to think at all about combustion and how
the engine works and the details of how the car goes forward. The
car abstracts away all those details for you. The car is sort of like acting a
facade for accelerating a vehicle. That’s sort of more what we mean
when we talk about facades in code. With code, usually, when talking
about facades, we’re using the facade pattern, a pattern popularised in the
book Design Pattern which is sometimes referred to as the
Gang of Four. What is the facade pattern? What does that mean?
Let’s say that I have a client and the client has to call three
different services to go get some data, right? So we’ve got
this class here, it’s got a function called Do Something,
and inside of that function it’s got
to go Call Service A and Call Service
B, and Call Service C. That’s great, no problem there. Then
your boss comes along, and your boss is like, you know, I think
actually, instead of service C, we need to use service D. So you’re like, okay, fine, did
that, no problem. That is okay. Then a little bit later, it
turns out that you need to replicate that exact same
behaviour in another part of the application. So now you have to keep track of
this in two different places. And your boss comes along, and
it’s like, actually, you know what, it’s not service C that we
need but service E. You’re like, I change it there. Then dang it, I forgot, I have
to change it over here too. A few months later, it turns out
there’s another place that you have to replicate the same
behaviour, and on and on and on, and you just start losing track of where you’re supposed
to maintain this behaviour. So this is where facades are
actually really useful. With facades, instead of having the
client worry about service A, B, and C, we can insert this layer of
abstraction between the client and the services, and this way,
the client doesn’t actually have to know anything about what is
going on under the covers. In our little general example here,
we’ve got the client, and we can take this code and move it into
its own class called a facade. And this facade now has the
function called get everythingEverything
which is containing the extra details of
how the data is being retrieved. In the facade, we can call the
facade and use the getEverything method in the facade. This is nice, if we need to make
changes, like change from service C to B, we do it in the
facade, and we don’t have to worry about it anywhere else.
Back in the client, we don’t have to change everything. If we’re doing the same
behaviour multiple times, we don’t have to change anything
anywhere else. What about facades in NgRx? To explore that, I have good
news for you. Now you’re all working for CERN,
the Council for Nuclear Research in Switzerland, you’re all now
engineers for the large Hadron Collider. If you don’t know what the large Hadron Collider is, they
have two beams that go as fast as the
beam of light and collide is to is to in order to try to find the Higgs Dbosun
particle. The magnets are cooled down to
cooler than space. That’s how the particle beams can go so
fast. We’ve been instructed to
re-architect the restructures the software that runs the large
Hadron Collider. The software looks like this. If you go to
the website, this is actually the dashboard that you can see to see this status of the
Collider, called Vistars. You can imagine, this is a large
complex event-driven application, right? You have to know the status of
the beams, the temperature of the
the status of the collide questioner, all kinds of things. When I think of event-driven, I
think of NgRx. You’ve probably seen this diagram. This is a
really creaky floor. You’ve seen this diagram. Me and Mike gave a talk that
used the same diagram and Mike uses it at
just about every talk he gives about NgRx. But the NgRx architecture is
famous for this indirection where the view
layer doesn’t have to know anything about how a state is
changing. Let’s think through how we might
architect this application with NgRx. Let’s think about changing
state with actions. So, with changing state, the
components, this puts the actions through the store, the
actions travel through the effects and reducers to change
state. For the large Hadron Collider,
we might have a host whole of actions,
the beam one status, the temperature of the magnets, and maybe finding the
Higgs-Boson particle at some point. If we use the actions correctly, we should be
able to go back to the log to see where the actions claim
from. We should be able to use actions
eight and use an action like start beam one. Perfect. What
about reading states? We read states through selectors. The
component can read a selector to read state from the store. How we would do in in the Large
Hadron collider. We might create selectors for
the beam one status, the beam two status, the magnet
temperature, the collider status – a lot of things that
correspond to the actions that we are doing. Then in our code, we do things
like store.select, have select beam one status. So let’s look
at our people one component here. So, in beam one, we’ve got our
constructor where we inject the store. We’ve got a turn-on function,
and, in this turn-on function we dispatch an action to start beam
one. Eave a selector for our people one status. beam one status. This is pretty
standard. Some people are not super happy with this. Some people don’t really like
the store, the component to know about the store. Okay, fine. Where could we use facades to
help this problem if we don’t want the component to know about
the store? We can do something similar with the facade pattern.
We’ve got our NgRx architecture here. We want to insert a layer of abstraction between the store
and the components, and that will be our facade. So what does
this look like? If we go back to our people one
component, we can abstract this code into another class. It’s a regular injectable,
basically a service called Beam One Facade,
and use our store here in the constructor. We will move our
turn-on method over to the facade, and we will move our
selector over to the facade. And now, when we go back to our component, we’re going to use
the facade instead of the store, the
instructor where we inject the facade, call the facade’s
turn-on method and use the beam one method for the facade
instead of the selector. We should have a drinking game
every time I say “facade”. Not necessarily alcohol – anything.
So the nice thing about this is the way we can extract a way the
implementation details of the turn-on method. In the turn-on
method, maybe we need to change the action that we need to use
so we can just make that change in the facade, and then we don’t
have to make that change anywhere else. I know now you’re thinking,
like, okay, this is awesome. Now the components don’t need to
know anything about the store,
facades are fantastic, this is everything I’ve ever wanted, and
I’m going to go out and use it right now. But it’s
unfortunately not that simple. There are a few things that we
need to consider a little bit more carefully. I want to reason
through this architecture decision here. So remember, one of the things
that we said was the magic of the facade
is that, when we need to replicate code and use it
elsewhere would be , we don’t have to make those
implementation details available everywhere. But if we think about NgRx, what
is one of the staples of good action hygiene, it’s that we
don’t reuse actions. Actions are meant to be unique. So we go back and look at the
actions we’ve decided to use, we have
this name space here – beam one, beam two,
magnets, collider – and the idea of this is that someone going
through the log years down the road there is a bug that comes
up, someone can go through and know exactly where everything is
happening. That’s one of the many reasons
that we make actions unique. So you might be thinking, I
don’t think this is going to happen. Let’s think through an
example here. Let’s say we are working on the
collider component. The collider has to know about
both particle accelerator beams, right? We think we know what we are
doing, so we go ahead and injection the
beam one facade and the beam two facade
and we will get super clever and have an observable for people
one status and observable for people two
status, and everything’s good to go, right. beam one status and observable
for beam two status, and everything’s good to go, right.
Your boss comes in, can you make one small change? It will be
super easy. Your boss is like, “It would
make more sense to turn on the beams from the collider
component rather than the individual beam component.” That
seems pretty easy. I’ve got boast the facades here,
I think all I need to do is slap in a new turn-on beams function, and
everything’s good to go, right? Boom, done, problem solved. And
there’s a small problem with this, though. Because we’re
actually reusing those actions. If we think about this, if
somebody runs that turn-on beam from the
collider component and a problem goes back and looks at the log,
this is a lie. This didn’t actually happen. Those actions,
we have no idea whether those actions came from the beams or
from the collider components. And that’s a big problem. That defeats a lot of the
purpose of NgRx. Another problem is, if we look at this a little carefully, this looks
suspiciously like reusing things as services, which, again, kind
of defeats the purpose of the indirection of the NgRx
architecture at the Redux pattern. We’re using reusing pieces of
state as services, and that’s not really what we want. If we were doing this without
facades, if we were doing this with plain
old NgRx, what we would do here? We would normally create a
specific action for this situation, right? We would have a collider action
of start beams and it’s a what we would dispatch to the store.
And then from there, we would have an effect, and this effect
would listen for that start beam’s action, and probably call out to some API, some fancy
CERN API that turns on the beams, right? Then we would have our reducer
which would listen for the “start beams” action, and the reducer would
update the state in the UI. And then, instead of seeing
something like this on the log with two different action types
here, we would see one action time, type, and we would
know exactly what was happening here. And, in doing this, we are
letting effects and reducers manage state and that’s what we
want, right? If we still want to use facade, if somebody out
there is no, we want to still use facade, we can still do
this, right? If we go back to our facade
here, the main issue with this is the turn-on function, because
what we’ve done is abstract a way action, and this
is the dangerous part. So what we need to do instead is just have a generic dispatch function
on the facade, and that way, the components will just dispatch
the action through the facade to the store. And now we are using facades but
we haven’t defeated the purpose of the NgRx architecture. Now, remember, we have had a
little bit of a problem with the way this is set up, because it’s
sort of suspiciously like using service architecture again, so
what are we going to do about that? There is another thing
that we can refactor that will make this a little bit more
obvious. So, if you remember, we were
using various selectors in our facades and being really clever
about it. We had our cleared our collider component and the
beam one, as you say, R status and the beam two status. Then
your boss comes by again. It’s always “Hey, Buddy, hey,
pal, I have one moring I need you to do, super easy, real quick, no big deal,”
but it turns out we actually want to know the status of both beams before we
can turn on the Kohl collider. We need a a Boolean that is a
combination of the two beams because we only want it to
return true if both the beams are on. This is easy, right? I’ve already got the two facades
and collectors. I’m going to do something easy:
slap in a new observable. I’m going to use combine latest. And
I’ve got my two beam statuses, and a map function that’s that’s
going to return a Boolean of the combined ones. Easy, right? the two facades and collectors.
I’m going to do something easy: slap in a new observable. I’m
going to use combine latest. And I’ve got my two beam statuses,
and a map function that’s that’s going to return a Boolean of the
combined ones. Easy, right? There’s another problem here:
we’ve introduced a performance bug by doing this. It is subtle and it’s not
obvious, but if we look at combine latest,
that mapping function is going to run more times than you think
it will. Let’s look at the marble diagram
of combine latest. So, with combine latest, the top
observable is going to emit A. The second is going to emit 1. As soon as it does, combine
latest will emit A1. When the top observable ecommits
B, it will B1, and then when B – so
that combine latest runs a value any time there’s a value for
East of them. There’s an extra instance of that mapping
function that’s going to run. So that mapping function is going
to run more often than you want it to, which is going to cause
some performance problems, because you don’t actually need
it to run any time either value changes. So how do we fix this but still
use facades? I’ve got really good news for you because the
NgRx team already thought of this, and that is whoaat
createSelector is for so we can compose
selectors, compose pieces of state that we want to keep track of,ee can use the
select beam one status, select beam two
status and use the Boolean function top now
we don’t have a performance problem. If we go back and think about
our service architecture versus NgRx Redux architecture, it
becomes a little bit more clear, because what we should have done is had a specific collider
facade, and this cleared collider facade we keep track of
everything we need. We have the store in the
construct, the dispatch action, and this time, we would have our
combined status observable that is the selector we’ve created to
compose together those pieces of state without messing with our
performance. And then if we needed other
selectors, like we needed to keep track of
the magnet status or temperature, or something, we
would could add that to the collider facade, that’s no big
deal, or keep it the way it is. Now we’re using facades that
doesn’t sacrifice the power or performance of NgRx. Back in the collider comment we
would use the collider facade, and
turn on the beam function, and use the combined status
observable off the facade. And now, we’re using the facades
in a way that works with NgRx just fine. So, facades can make your life
easier, which is awesome, but there’s a little bit of nuance as to how they’re
using in order to use them cell. The thing to keep in mind that
the power of NgRx actually lies in the architecture. So we go back and look at our
NgRx diagram again, our infamous NgRx
diagram, where we have components, effects, and
reducers, we want to make sure we are changing states with
actions that are unique. We want the components to dispatch those
actions and have them route through the effect and reduce
the changed state, and then we use our selectors to read state
from the store. So, it is possible to use NgRx
with facades by inserting a layer of abstraction between the
store and the component, but we have to do so in a little bit of
a nuanced way. This reminds me of something that one of my favourite teachers in
computer science said which is prefer duplication over the
wrong abstraction. So, it’s easy when getting
started with NgRx to get a little overwhelmed with perhaps the boilerplate – sorry,
Brandon. It feels like you’re writing a
lot of code at first. This facades pattern seems like
a welcome relief from doing in a, so it is really tempting to jump tothat,
so it is really tempting to jump to facades quickly. If you do it too quickly, you’re
choosing the wrong abstraction by doing it too quick. Ken Dodd said avoid hasty
abstractions. You want to think the
architecture decision before you naïvely use facades, but it is a
way to do so that is compliant with NgRx performance and power.
So the issue here is that it is sort of like you spent all this
time to craft this beautiful staircase of NgRx architecture,
and then you sort of decide like, you know what, up at the
top, I’m going to jump through a hole in the floor in order to
get back down instead of going down the staircase. So, to conclude, I’m going to
use the voice of reason himself, Brandon
– oh, no, that’s in a minute, sorry! To conclude, if we’re going to
use facades, first and foremost, don’t abstract away your
actions. Secondly, make sure that you use
createSelector to create your state and don’t hand-roll your
observables. Now I’m going to refer to
Brandon Roberts and say if you’re learning NgRx to manage
state, don’t jump to facades too quickly because you’re going to
lose a bunch of time. First and foremost, learn how
the underline machinery of NgRx works, and then smartly
implement facades from there. So, you can find the slides as
well as an article I wrote for a blog on facades. It has its own sample code and
all of that, and also of course, you can always feel free to
either come up to me, ask me questions about NgRx or authentication, or upgrading,
lamas, or chickens. That’s basically it. Thanks so much for
your time. I hope you have a wonderful rest of the day!
[Applause]. – Thank you so much, Sam Julien. So we are going out on a break
now, half an hour before the panel. Don’t forget to submit
your questions to the panel through slido.com.
We will be back at quarter-to four. Back here. See you later,
everybody! [Break].
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. . –
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. . .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. . [Music].
– Hello, everyone. Welcome back! Let’s hear it! Can’t actually
see you, so let’s hear you. Are you there! Okay, so we’ve managed to get so
the end of AngularConnect, but just
before we go, we’ve got a few things, including the Angular
Panel. They’re all there waiting to come on stage. But, prizes! I
haven’t actually got the clicker. Someone else is going
to have to click for me. We’ve been asking you to tweet
over the last couple of days. We now is very excitedly
announce the sponsor prizes. Okay, sponsor prizes. So let’s hear it for Progress
sponsor prize winner, Lucas! [Applause]. I don’t know where
you are, but congratulations. And Nrwl’s sponsor prize winner:
Thomas. Congratulations! – Domasp . Domas. Now we’re going to move
on to the Twitter winners, I think. Yes. So, here are our first two:
Jamie. Apparently, you’ve been saving that T-shirt for a long
time. Well done, you’ve won not
another T-shirt but a prize. Come and get it from the front.
Megan ‘s here. Let’s hear it! [Applause]. So, if you’ve been in the lift
at all this couple of days, you might have noticed Bonnie doing
some selfies, and so, to recognise that, Bonnie, come up,
you’ve got a prize! [Applause]. There are a whole collection of
these. You should have a look on Twitter. Next slide. Next slide. Okay, and up next, Tracey. Thank
you for all the tweets you’ve been doing. Come and get a
prize! [Applause]. And she’s not here. She’s
probably tweeting somewhere! And finally, Danielle, thank you
for tweeting. Come and get a prize. Yes, up next, is our tweet er
with an exciting prize of a free ticket
to Angular 2020. Clark, where are you? [Applause]. 3 come on, we can clap louder
than that. Oh, he’s not even here. No. Okay. Well done, and
we will see you next year. We will email you. Okay, so, thank you. You could have, but we didn’t do
that. So, last night, we had some
lightning talks, which I’m sure some of you attended, and we
really enjoyed this lightning talk, so we thought we would
spend just five minutes, and we are counting – five minutes – for Jo
to deliver the lightning talk from last night. Joe’s a nonbinary senior
engineer with Neol, a fascination with the
intersection of beauty and complexity leading to perform
through education, performance, and poetry. Please your hands together for
Joe! [Applause]. – I need this. I’m not miked up
otherwise. Hello. First things first. Andrew, the stenographer.
I’m so sorry. CAPTIONER: So am I!
– Try and keep up! CAPTIONER: I was there last
night! [Applause]. – I’m sorry for that as well. – A is for angular, what I’m
going to attempt is poetic oration of Angular aspects. A
few things have changed the last time I spoke. What I wrote is
revoked. I’ve got 26 letters to get through in runtime. B is for
browser which we all build. I know this is something that
causes us pain. What is the ultimate gain? We test different
systems as much as we’re able. C is for call where we find
content child, modular provides, common we need is the name we
might suggest. D is decorators, who are they
for? How do we add syntactical
sweetness? They are function that is bring grammatical
neatness. Bundles with sizes that weigh so
much less, how it’s all done, I don’t know, I confess. E is for elements, exciting and
new, portable Angular components for you, not only easy to land on tea the fly
– future big project shipped. F is factors and forms driven by
templates. This is one of those areas where preference is
muddled and it seems like it could leave developers troubled. Each approach has their – but
it’s worth looking up – under G we
find, the methods on are more or less simple enough, tough with
the time rushing on, I won’t try, more sketchy rhymes, I
might high. H is for http our host, most of
the devs in this room will probably get but you haven’t
used the host decorator yet. I is for Ivy, or render three,
simpler and faster and smaller than a flee. It’s out there to
try if you want to have fun. After regulatory, getting near
so it’s said, what feature will people focus on instead? The docs are unsatisfactory,
this JSON 2 which as it is impure, it should knob the
impure, at the moment we write, and the properties within. K is for key values using the
map, directing our changes throughout the map. They look up
expression change after it has been checked. L is location, the way we might
tell, the strategy used changes how the address of our pages
will look and whether the mess but instead of all that,
possession just hashes and bugs. Module is one of the main
building blocks, it sends data between the UI and web
backbrand. It’s important will grow in the future, I bet. Navigation is next, and the
schema, all clauses beginning – onwards to O
for onDestroy, there’s nothing that seems unfamiliar here, just
parts of the system we hold near and dear. A curious thing if you if you
look up for outputting strings. For the low Carl Q is for querying all of the
ness we can query, we can query the content and be sure if we
updated anything new. To observe all the things, be
struggling with state, you will learn … if you could limit
yourself to subscriptions ending with a simple emission. Is W – work flow improvements,
they could be dramatic I look a better approach to the code to
maintain. May not have a need for schematics at all. T is for
TypeScript. Not as marred as you thought,
although lately it seems there’s a war being fought between those
who are constantly Skyping but JavaScript was made to be free
and guessing what everything does is the key. U brings the up date – separate
them by route don’t fall into the trap thinking this is
something we could means it is one of the things that we
should. V is children, confeint F and
view encapsulation but note the distinction between the content and – W
brings us to classes that look as though they all start with the phrase what the f
… . The intent isn’t to make you
smirk if performance is key, it may be what you’re using. X is for XR factory and what
else is under this letter to tell. It’s one of the things
that allows us to test. Why is – Y is for you, all the
here seated who wrestle with code and re-Maughan undefeat
pre-rendered document – remain undefeated. Z is for zones which I say we
will no longer need them one day. I’m, I’ve rushed through a lot
in a very short time, and now I think I’ve used all my Angular
rhymes. Thank you! [Cheering and applause]. [Applause]. – Wow, thank you so much, Jo! So, just remember, we have
recorded that, so, if you want to play it
back in half speed or quarter speed, then you can do that, but
that was amazing! Thank you so much. Without further ado, can I
invite the Angular team up to the stage, and we will get
started with the Angular panel. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. . – Everyone got a seat? Okay, so let’s hear it for the
Angular Team Panel! [Applause]. Okay, so I just want to thank
everyone for submitting questions. You may have seen us
playing around with it a bit. That’s because there were
duplicates. We didn’t necessarily have time for all
the questions, but hopefully we’ve got a good selection to
interest you. And thank you very much for submitting them. So I’m going to start with a
more general question. So, this is for each of you. What can we do as a community to
help you? Who is going to start?
– If you’re a library maintainer, you should upload your project to
Minko’s repository – I’ve forgotten the URL – but if you
were around during this week, you would know what it is. Go
and look on the videos. Make sure that it builds and
works with Ngcc because that will work with the rest of the
people who use the library make the transition to Ivy
easier. >>It’s been moved and easier to
find out. – Checking out Ivy, testing your
application, and finding issues if you come to any problems now
would help us so we have less stress after the …
>>Speaking of issues, when you write an issue, make it as
simple as possible, and explain specifically what do I click on?
What do you expect? What should actually happen? A lot of times, I look at
issues, and I have no idea what you’re trying to say. So, assume
I’m an idiot is a pretty good assumption and go from there.
The simpler the better! – If your stacklets has a folder
with a bunch of components in it, you’ve gone too far. – This is for all of you. I would say if you maintain a
library, just kind of feel the responsibility towards the community, so, like,
make it useful, but also make it right,
and like profile it, like many people would rely on your work
to have a good time, so, just, you know …
– So, to continue on, it is very important that, if you have a
bug, to provide a reproduction. – Small reproduction.
– Yes! – The minimal. The minimal quote needed to
reproduce your problem, and, if you don’t
actually provide a re production in a
git, just just in code. Always provide the version of what your Node version is, your CLI,
framework, and you might be reporting an issue that was
fixed in a patch version that was just released.
– So,or me, if you want to contribute to Angular, I would
highly recommend going through the pull requests, because it allows you to see basically what
a certain change needs for the code that is behind that which
really helps in understanding what needs to be done for
getting stuff changed, and so that would be it for me. – I already answered it. I will
let others talk.>>
– We have more than a million developers. It can come from any
of us here on stage. Be engaged and be involved with
the community. Go and help other people with
issues on Twitter or whatever you see somebody else, because become the local
leader through a meet-up. The only way to scale to a million
people is if we have thousands of experts below, and thousands
below as one. Yes. – And I want everyone in this
room to try out Ivy, because there are a lot of us, and
everyone on the live stream. I think we can write some crazy
code and catch every possible edge case so that what we write
in the future will continue to work. – Yes, I think maybe some
documentation helping to write some documentation, even the example of some exactly
usage would also help other users to use Angular better. – So, I think for me, again, the top thing would be submitting
issues and having good descriptions so
that we can basically produce, locate
the issues and fix it. But also what was said, if
you’re looking to contribute to help,
you can do like fixing something, the docs that you read, and you see a typo or
a tiny thing, and, if it seems tiny,
it’s – don’t be afraid to submit even a fix for a thing that you – that seems
trivial. – Tell us when something doesn’t
work, clear instructions, minimum viable reproduction,
like Miško was also saying. Even better, please fix it and
submit a PR! – Rado touched on what I wanted
to say which is keep being awesome to each other. I love
being in the Angular community. Guys and girls are some of the
most fantastic, respectful, amazing people to work with, and it just on a
day-to-day basis for me, it’s really motivating to work on a framework that has
such an amazing and loving community. Thank you all.
– Talk to each other. Oftentimes engineering ends up
getting overly focused on the technology and the choices, and
the code, but every time you open up and talk to someone and
share your problems, share your successes, you’re going to
benefit from that. – Are you saying they should
connect? – You all took everything!
[Laughter]. So, I will extend on what was
said about issues. Yes, minimum viable reproduction
of issues, and if we feel like it didn’t quite make sense to us, and we
ask for reproduction, please provide that reproduction. There
are a lot of issues that get opened, and somebody is like
this problem is happening, and here’s why, and we’re we don’t
quite know, can you do this thing, and then we never hear back, which just leads to a lot
of orphaned issues. So follow up on those things, I guess. – And, of course, from a
non-technical point of view, kind of building
on what Stephen and some others said, you can try running an
Angular conference, because that will help bring everyone
together, and learn more about Angular, and it may be that’s a
little bit too big a jump, you can start by running a meet-up
or going to a meet-up, helping it, and giving test automation.
It’s a lot about the community as well as just the technical
things that you can do to help us as a team. – So just worth saying, we have
had a lot of questions on this, which
you’ve combined, so I18n which is which
is there’s, what is the – which
seis there’s. internationalisation. Any update on the i18n?
– So we’ve answered this question a couple of times at
various points during the day, so, apologies if I’m
repeating myself. But, internationalisation is
going to be an important part of Angular
v. We are putting in place the
basic machinery to support9. We are
putting in place the basic machinery to support a new
pipeline for making transitions faster and more versatile for
you as developers. I’m not going to go into the detail, but the
main point that you should take away is that we’re going to be
providing primitives which you will be able to build upon,
people in the community, or maybe us within the team, to add
features. The difficulty about talking about runtime
translation is that it means a lot of things to lots of people
– like everyone I spoke to had a slightly different view on what
it means. We need to spec that out, work out what is
appropriate for us to build, and what is appropriate for the
people in the community, or even individual app developers to
build, but our aim is to provide a basic level that you
can build upon whilst still maintain
backwards compatibility with v8. It’s a bit general but it’s a
big panel. – I was going to add that we
really care about internationalisation. In the keynote, three slides all
about internationalisation. We were running over time and I
deleted them. I’ve been regretting it over the
last two days because the questions we got were about
internationalisation. We care about it. We will be on par with
what we have today in v9 but it’s going to be
much faster, and we are designing a way that will enable run time
internationalisation but there’s more work.
– I want to add a little bit to it that keep in mind the first
step is just to replace what we already have, so all the new
features will come later, so it’s not that we don’t think
runtime is important, it’s just not Strictly required to be backwards
compatible with what the new engine is, so
that’s why we’re doing that thing first. After that is done,
we will do other things afterwards.
– The last thing I would say is the conversations I have had in
the last two days have been really informative for me being
involved in the implementation of this stuff, with , so if any of
you are using internationalisation and
autograph view on how you would like to use it, please get in
touch with me, and I appreciate your views because it would help
guide our future designs. – Great, so we heard in the
keynote about Ivy and the plans for when that was going to be
released. The question is what’s up next? – So, in version 9, it’s all
about enabling applications, version
10 enableing for libraries, and starting to build up on the internal APIs
that Ivy enables. I showed some of the examples of that in the
keynote. We have some explorative work
going on, related to the server-side rendering, and the hydration of server-side
– many other experiments are going on. I don’t want to go too
much in details. We don’t want to comment too much on features
just yet. Ivy is still the number-one
priority and getting that out is what we are focused on. That’s
what we are primarily focused on.
– Where do you draw the line between useful performance
optimisation s versus un necessary micro optimisation s? Should I care with monomorphic
and mono morph fix and day-to-day
development? Surprise, surprise! s? Should I care with mono morph
fix and day-to-day development? Surprise, surprise! The short answer is in most
cases when you write your application code, you should
make it look simple, maintainable, and usually the VM
does the right stuff. Now, for something like a
framework, we’re a little bit of a different boat. For a couple of reasons: one is
usually we have to call into the application code, and we call
into the application code, we always call it from the
lame occasion, like we have a bit of code to call, and is to so it is
responsible to call,’s ng Init so that becomes
megamorphic. It’s probably not the same
problems you face as a an applications developer. It’s
good to understand these things and good to en large your
understanding how the VMs work and it’s
behaving strangely, but I would say for most cases, in
application development, this is not an issue. It’s a lot more
interesting to make sure the code is simple, maintainable
first. Second is if something is not
running fast, usually, it’s some macro optimisation that is off,
and you should focus on that first. And then micro optimisation s
such as megamorphic calls and inlining only matter in super-tight code which
is un running over and over. It’s rare that such code would
be written by the application if possible, and that’s why it is
useful to know, but it usually doesn’t happen.
– Don’t forget to measure and profile. – Yes, like, I think if there
would be one advice, it’s just open a
profiler, have a look at it, because most of the time, there
is one or two very obvious things that just jump at you. Like literally screaming and
saying just go and fix me. It’s like they don’t have a
chance because people don’t open it. Number-one performance advice is
ask while you measure. – So it’s been really
interesting to hear during the conference about
the inner workings of the Angular team. What was your motivation behind
this transparency? – Transparency is very
important. Transparency also extends beyond
core. code. Angular is more than code.
When you understand the internal workings of something and the
rationale behind the decisions and choices we make, you can
trust it more. You work with it better, and you become more
productive. That is the motivation.
– Yes, I would add from my perspective, another part of it
is demystifying how things work, so that it is more approachable. If you actually understand the
inner workings of our team, our team
doesn’t seem scary. I worked on components before
the sub framework stuff and I was scared to submit to
framework and I sat next to everyone! I imagine for everyone
else, it’s got to be even more scary. Making our project more
approachable, it’s definitely a goal of that.
– I also find it interesting when somebody puts PR and says why
can’t you merge it? It takes two seconds. Actually, it doesn’t.
– Merging takes two seconds everything before merging days takes days!
– All these pieces, by understanding all of these
things, it’s easier to understand that that things are
not quite as simple as you think they are. – This question is for many of
you as who want to answer it: what is your favourite Angular
release and why? – I like @next because you can put that
in your package JSON because you’re always on the latest
Angular and have the best features. Nothing can go wrong
then! [Laughter] . – Not at head or master?
– I’m not crazy! [Laughter]. – That’s what Googles uses.
– Yes. We do test that it always builds
an npm package, so you should be good on master, actually.
– Maybe I will take that lead. – For me, it’s the releases we
made along the way, however that saying goes.
– I personally really liked 8.0 because differential loading is
I think really a fantastic manifestation of this idea that we can make
Angular better by tweaking your apps how
they build and ship everything. If we can do that in every
release been make your apps better, not have to change
anything, we would do that. [Applause]. – And to get a little bit
sentimental, my favourite release is 0.10.12, because this
was when I first started using AngularJS and it’s like when I
first started interacting with the Angular team and meeting
these guys. You know [pretend crying] really
upset. It was a wonderful experience. That was the moment
when I joined the parade. It’s been fantastic ever since. – For me, it’s the one that we
already released, because that’s when all the work is done, and
people get to enjoy what we’ve done. If I had to call one out, I
think v6 was pretty cool because that’s
when ng update came out and that made it really easy for people
to stay up to date. – Someone was going to say the
future one where you get to delete –
– I love all my children! – Ahh!
– Equally! – Someone has commented that
Angular material was hardly a topic. Can we get a status
update? Material was hardly a topic. Can
we get a status update? – Sure, so, Angular Components
as a whole is mostly heavily focused
on – is creating – I’m blanking entirely
on the name of them – on testing
harnesses, and building those testing harnesses for the
Material components themselves as well as moving our Material
components on top of the material design teams,
MDC components, so that we can stay completely up to date with
what the material design itself is. I think that’s the main focus
that’s been happening for the team. The reason why it wasn’t
specifically talked about is when we planned who was going to
come here, I was on the components team, so I was going
to do that, but now I’m focused on dev
Infra, so we didn’t have a components talk.
– What advice would you give to a project team that’s just about
to start upgrading a medium-sized project
from AngularJS version 1.7? [Laughter].
– Oh, I guess I can answer of this one. Do you want me to take
it? Most ly because I’m on AngularJS
1. 6 and not 7, so a difference
between them, but at least the advice that helped my team the
most is to plan out how the components interacted with each other, so, if you migrate them
at least from bottom up, there’s a couple of different
approaches, but knowing what the dependencies are and really
thinking of your project as a whole when you’re going about
migrating it, it helps reduce the burden halfway through
saying I messed it up, it’s not a good order and made my life
more complicated. – I want to say that Ivy doesn’t
change anything in that regard. It’s not something that should
add extra work for something. We keep working on ngUpgrade and
adding small features that will make that work easier for you, and maybe the
work has slowed down while the focus is on Ivy, but with Ivy,
there will be more work on that. There has been some changes that
would make testing easier, like when you test services with some
helpers. But other than that, it’s not
something that has been mentioned before. And planning out, and having
like your AngularJS application be in a good state, writing the
best application you can before starting the upgrade would make
it a lot easier. – Also, what I’ve seen teams be successful with is convert the
route of the application to – the root of the application to
Angular as soon as possible so you can lazy load AngularJS and
build most of the application, the main screens, with Angular,
and the least frequent pages you can lazy load AngularJS and lazy
load the rest of the application and still keep it running. – What are some of your
favourite blogs, podcasts, or any other resources that you can
share with us? That’s open to anyone. – They can al once or generally?
– Whatever you want. – We are I like one called –
it’s a philosophy podcast. – My kids love Wow in the World. It’s awesome done in a . It’s
science done in a humorous way. It’s funny for adults too.
– For me, it would be Angular In Depth. It’s an awesome forum to learn
about advanced Angular stuff, so,
really I do recommend to you go visit there. Thanks, Max. – I would say Google Talk. Especially the ones that are
focused on brain science, psychology. It’s surprising to
me. It had a impact for me as a
developer, say, like, it’s all about languages, and frameworks,
but we’ve got our brain, we kind of need to understand how it
works. So there are Google talks on
this. – It might sound silly, but
Twitter. I know it’s old and probably
will be over in the next couple of years but for now, web
development is very, very active on Twitter. Ignore the trolls
and look for the great articles and content that people are
sharing. – Yes, the formation, … if you
follow the right people. – I really liked to listen to
NPR1 which is a podcasting application that suggests
podcasts from all around the world and you get to be exposed
to many different disciplines. It’s not just engineering, it
can be psychology, whatever, history. I find history very interesting,
you know, there are so many things that happen for a reason, and we just
see the artefacts now and don’t know how it happened, and
knowing why we are are where we are and how things happen is
very informative. – Anyone else? No? I like how you said “Things
happen for a reason” and not “Things happen
for a good reason”. I like that. – I think we avoided saying many
of the potential Angular-related ones just because there are so
many great ones out there, but if we picked out too many
individual ones, it would be unrepresentative, so that’s
probably why we all generally tend ed to steer on to the more
general sides of things, just to be safe.
– Fair enough. – So, other than Ivy, what other
features of version 9 is the team excited about? – One of the features that I’m
really excited about is the simplicity
to build universal, so, previously, we had to call the server builder, and
after the server builder there was another webpack build and
now it’s just one. The – you can build your server TS
and your whole server part. One build. – We can also en able bundle ing
of dependencies on server, and
hopefully coming soon optimisations of JavaScript on
the server as well. – Most of the team was really
focused on Ivy, and Ivy’s the v9 primary
feature, there are small regularly improved dependencies,
update dependencies, like updates are updates, stuff like
that, but we’re not working on any bigger features in v9
besides Ivy. Ivy is big enough by itself. – We are adding to Components. The YouTube player, like a
component that reaches and does the
YouTube i frame API management as well as Google mobile apps
Maps component. – Are you still working on
improving the bundle size and performance?
– Yes. – Next one! – I could expand on that, I
guess! Yes! [Laughter]. – They’re like Y-E-S. We’re sorting on the bundle
side, specifically we want to look a
bit more on more of our fixed costs, so one thing that Ivy
already does extremely well is we’ve reduced our variable costs
so the code we generate for you is much
longer smaller than is it used to be. Now we are going back and
cleaning up because a natural consequence of moving some of
the logic to the runtime and dividing all of our
functionality into more pieces, naturally, it’s going to get a
little bigger. Now we are going back and
removing everything we’ve done and reducing the size of the
framework. That will improve it. – [Inaudible]. – We’re also working on
compression and making it compressible. – What tool would you suggest to
use for end-to-end testing of an Angular application? – So, as you probably know,
Protractor is the default testing in CLI. It’s the primary
way to test applications at Google. We actually did a deep dive into Cypress versus web Java testing,
and determined that we cannot afford moving away from testing
against real browsers just because we have so many
mission-critical applications that need to be tested on real
browsers. If you don’t know, Cypress is chrome
Chrome-only for now. We know that Cypress provides
many benefits when it comes to the open experience, and
reliability, so, if you can afford testing only on one
browser, you can install Cypress into your project and start
using it. If you want to test against real
browsers, if that is your business requirement, then Protractor and
Driver are the best choices. – So we’ve got time for maybe
one or two more questions. Is there a way to get custom
decorators shakeable with Ivy? – Can you repeat that?
– You want me to repeat it? – Yes.
– Okay. Is there a way to get custom
decorators tree-shakeable with Ivy?
– Ah, tree-shakeable, okay. It’s probably not a great idea
to be threading custom decorators right now, and the
reason for that is because the spec is still evolving, and it
may change a little bit before it lands in its final form. The problem with
tree-shakability in custom decorators is a problem at the
language level, the way they have to be downlevelled right now into ES2015 and ES5 makes it hard for
them make good decorator classes. A decorator is almost
by definition a side effect. It’s going to be changing the
class and doing operations based on the
implementation. I would wait until the decorator spec is finalised and, at that point,
the optimiser tools should get better at dealing with them. There’s not much we can do in
Angular to make that experience any better at the moment.
– Okay. And so our last question:
optimise runtime code inside Ivy is very interesting. Is it tuned
for V8? Is it fast on IE or other
browsers as well as Chrome? Try and keep that to five minute,
the answer. Or less. It’s quite an easy question! – So I would start – it’s
definitely not tuned for V8. It’s just I think that
performance-checking tools are like the best in Chrome, I guess, right
now, and it’s just the best … I’m not
aware. So, it’s just like the easiest
for us to understand what’s going on inside the virtual
machine using those tools. But I believe that most of the
optimisation s that V8 is doing is like the principles are the same, so
the browser, mike megamorphic codes will be slower in all the
browsers. So, there is a possibility there
like, you know, one artefact of our us
using V8 as the primary tools, that we
will have specific optimisation s which is targeting V8, but I don’t think
we should be slowing other browsers. – In general, these techniques
that the VMs used are well known and
they’re used not just? JavaScript, in Java, or any
other VM environment you have. It’s not specific to a language,
not even a browser. It’s just a standard set of
tricks that that the authors used to deal with these
particular problems. – Thank you. So I think
unfortunately we’ve run out of time, so can we hear it for
the Angular team, and thank you very
much for being so transparent! [Cheering and applause]. Okay, so we are getting very
close now to the end. Can I invite Pete and Ed to come
back up? I think Ed’s going to hide down there.
– Okay, then! So, of course, none of this
could happen with lots and lots of help. So I’m going to run through all
the people that I thought of that we need to thank. If there
is anyone I forgot, I’m really, really sorry. Come up and tell
me, and I will thank you personally afterwards.
– I think we are going to start a round of applause.
– We are taking a leaf out of Joe’s book and do this as fast
as I possibly can. You can help me by clapping and cheering
while I read all of this out. Off we go! Thank you!
[Applause]. So all the staff at White
October Events, the QE2 Centre, hosting
team, Bonnie – all our speakers,
workshop givers, the ngGirls mentors, Dan
and Sarah, Erwin, white coat captioning, thank you so much, AOTV did the
live streaming, On Productions who made all of this work, and of course all
of our sponsors who are on the stage all the way along here,
especially ag-Grid. Thank you so much, and finally,
thanks to all of you! You’re amazing. Keep up the good work,
and we look forward to seeing you next time! Under five
minutes! [Applause]. – It’s an absolute pleasure. As they say, that’s it, folks.
Thanks for coming. So we look forward to seeing you next year.
We will be releasing the dates for the next year’s conference
very soon, so just keep an eye out on our website and Twitter
stream and we look forward to seeing you next time. Thank you
very much for coming. Have a safe journey home. [Applause]. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .