DEV Community: Joe Eames

Const Is A Lie In JavaScript & Mastering Unit Testing

Joe Eames — Thu, 03 Dec 2020 17:29:36 +0000

Lately, I've been posting a bunch of really fun content in a series called Mastering Unit Testing on Twitter. The latest tweet is here on the difference between DAMP and DRY in unit testing.

Please go give it a look and like/retweet.

Const is a Lie in JavaScript

The const keyword in JavaScript is a lie and a waste. I recently tweeted about how const is a waste and had a lot of interesting discussions.

But here's the thing about const in JavaScript: it ONLY makes sure that the reference isn't reassigned. But when you use a keyword like const, it implies to you that the thing you're creating is constant, and will remain unchanged throughout the life of the reference. But that's not true. That's not what const does. Even with the best IDE's of today, nothing about this changes.

So this is totally valid:

In JavaScript, we use variables that point at primitives sometimes, but we very frequently point at objects/classes that hold multiple pieces of related data. Even if we use const, this data can be changed at will as above.

Ultimately, const is a little better than a comment when you declare a variable.

So there are two ways to improve this. First, follow the long time tradition of making constants all uppercase.

The second and even cooler way is to use the Readonly type in TypeScript. Thanks to Val Neekman for this sample:

And now, you get REAL constants, not half ones…

Happy Coding!

Signup for my newsletter here.

Visit Us: thinkster.io | Facebook: @gothinkster | Twitter: @gothinkster

Don't Use The Date Object

Joe Eames — Mon, 16 Nov 2020 16:04:33 +0000

JavaScript has a nice Date Object. It can do all kinds of cool things like tell you the current date and time, etc. Lots of languages have a similar facility.

And you shouldn't use it.

By that I mean, you shouldn't use it directly.

Let me clarify a little bit. I don't mean don't use date objects, those are a fundamental data type in JavaScript (or your preferred language). But what I mean is that you shouldn't directly use the functionality that tells you the current date and time, or some calculation based on current date/time, such as getting tomorrow's date. Why?

Because the date and time is an interaction with an exterior system. Because of how languages incorporate them into basic functionality, we have a hard time seeing that, but you should view it the same way you view the HTTP call that charges a credit card. Would you access the XMLHTTPRequest object directly from your code and hardcode in the URL to charge a credit card? No. You abstract that into its own functionality.

There are two reasons we do this. The first is that the code is complex and we want to extract it to a simpler interface. That really doesn't apply with getting a date & time. But the second reason does apply. And that reason is that extracting the functionality to somewhere else allows us to test and build our system rapidly by creating fake situations.

Let's examine a simple application that sends you an email on Wednesday evening at 8 pm to remind you to take the garbage out. How can you test this functionality to assert that it's working? Wait a whole week until Wednesday evening at 8 pm? Definitely not. Would you modify the system date/time on your development machine? Please for the love of all that is good and holy and bug-free don't do that. Maybe you can make the trigger date/time configurable, and when testing, keep setting it to 1 minute from now. Even that isn't the best idea. To test you'll have to keep changing settings in your development data store.

Instead, imagine you coded your system something like this (I'll use a bit of pseudocode):

Ignore my abstracted pseudocode to make this more readable (JavaScript dates are terribly unreadable). The key here is the "myDateClass" object. I wouldn't actually name it that but you get the point. This isn't the Date() function. This is something else. This class wraps the Date() object/function. The same way that you'd wrap the native XHR object, or any other functionality that accesses an external system. That way you can easily test your system by providing an alternative implementation that makes "now" exactly what you want it to be.

There are other ways to make this work. You can treat the IsTimeToSendEmail as the abstraction that you fake. You don't need to wrap all the functionality of your built-in Date object. But whatever you do, use an abstraction.

This is the proper way to use the current Date/Time functionality in a system.

Most developers don't automatically see the current date/time as an external system, but it is. So abstract accessing it away in its own function/class/service/whatever makes your code easier to write, read, and maintain.

Happy Coding!

Signup for my newsletter here.

Visit Us: thinkster.io | Facebook: @gothinkster | Twitter: @gothinkster

What's new in Angular 10

Joe Eames — Thu, 12 Nov 2020 17:47:29 +0000

Angular 10 is out. Knowing all the newest features of a tool can be very important. So let's break down what's new in Angular 10:

A big fat nothing
See #1

Yeah, honestly, there's really nothing new. Ok, there are a couple of tiny changes: Angular Material has a new date picker, and there's some minor changes to things you almost for sure don't use.

So does this mean that it's a problem? Disappointing?

Nope. Why? Because first of all, upgrading to 10 will be super easy.

Also, this matches their release cadence. A new major version every 6 months, regardless of how many features make it in. It's different than other projects run, but it's predictable.

It also really matters as people look at Angular as a true enterprise framework. Enterprises need stability. Small, incremental, easy-to-update changes are good for an enterprise. The last 2 versions of Angular have been pretty darn simple on the updates. That helps you keep your project from getting stuck on a specific version because upgrading is just too much work.

So here's a tip: how to update Angular to the latest version with great ease and simplicity:

ng update @angular/cli @angular/core

You can see the docs for that command here.

And generally, that's it. Updating support is a pretty nice feature of Angular.

Happy Coding!

Signup for my newsletter here.
Visit Us: thinkster.io | Facebook: @gothinkster | Twitter: @gothinkster

Has The Modern Web Made Things Better?

Joe Eames — Mon, 09 Nov 2020 16:58:43 +0000

There's been some fascinating discussion and debate recently about the modern web, and whether what we often take for granted as "the right way to do things" is really better than "the old way". A lot of this has been centered around Hey.com, the new email service that's taking the world by storm.

Now if you're wondering what is the "modern web" let's use a pretty general definition. The modern web is a web app using some kind of front end framework - angular, react, vue, etc. with some kind of API server - node, .NET, Java, or even serverless cloud, and a back end that is possibly relational, but very likely NOSQL, and all the various bits that go with all of that.

The recent version of this debate started when Tom Macwright posted a very interesting blog titled Second Guessing the Modern Web. Well worth a read. In response, Rich Harris, of whom I'm a great admirer, posted his In Defense of the Modern Web.

The main points by Tom Macwright were basically "JavaScript is not faster than No JavaScript" which on the face is quite true. Adding overhead to do more still adds overhead. But in the defense post, Rich Harris points out that logic can give you things like caching, lazy loading, and make decisions that actually do improve performance while also improving functionality. Ultimately both are right. JAMstack is a great method that maximizes performance, and a key piece (although not necessarily required) of it is pre-rendering.

This is all interesting, and I highly recommend you read both blogs, but things REALLY got fascinating when Hey.com posted their tech stack.

For some background, Hey.com is a new email client that bucks the trends of most email clients with its feature set, and promise of no ads. It's a paid service at $99/year. It's built by the same people who created Ruby on Rails, and who run BaseCamp. It has been wildly popular, but their tech stack reads like something built 12 years ago. They use Rails, the only client-side rendering is Stimulus, a very lightweight JS framework, and some "magic" they discuss, and MySQL. Eschewing the typical "we must use NoSQL" thing.

The people involved have long been proponents of optimizing for developer happiness and productivity. They use Ruby on Rails for everything, which is very interesting because although Rails is a server-side rendered framework, and the "modern web" looks on server-side rendering the way Obi Wan Kenobi views blasters. Yet, Ruby on Rails has long been viewed as one of if not the one technology most loved by its practitioners over basically anything else our industry has produced, although many Smalltalk and Clojure practitioners would beg to argue that point. Nonetheless, there is a very prevalent feeling among those who have used Rails, that nothing they did before or since was as productive and enjoyable. Your own mileage may vary.

For this and many other reasons, the team behind Hey.com chose to use Rails with minimal client-side rendering. This twitter thread documents the stack and many of the surprised and frankly judgemental responses to using this stack.

For your convenience, here's the breakdown of their stack:

Vanilla Ruby on Rails
Stimulus (minimal front end "framework" for rails) and a few other tools for front end interactivity
MySQL
Redis & ElasticSearch
AWS/K8S

Again it's fascinating to note that this tech stack is very much NOT the "modern web". No heavy front end framework. Almost exclusively server-rendered. Relational DB. And they're doing well. By all reports, they're doing really well.

So does this mean that the "modern web" is really just a bunch of empty promises and unnecessary cruft that we can abandon?

Perhaps the most interesting response to that original thread is this response here, where Rich Harris basically says that although the app is great, there are a few things he would expect of a modern app that don't exist in Hey.com because of the lack of client-side rendering.

Take Away

This discussion leads us to some interesting takeaways. First, you don't have to use the "latest and greatest". First, mastering a tool will often be more effective than constantly switching to whatever came out in the last five minutes. Second, new tools and techniques can give you capabilities that don't exist in older ones. But perhaps my favorite takeaway was that we are looking at what a top-notch team can produce give tools they have been mastering for years. This probably indicates that this isn't a good reference point for all of us "average humans". When you see a true master using a tool and think that the difference is the tool, and not the hands using it, you may be missing the forest for the trees. I'll illustrate this with an apocryphal golf story.

A man was golfing with Tiger Woods. Tiger hit a particularly good shot, and the man asked him which club he used. Tiger didn't reply. Instead, he went to his bag, pulled out two more golf clubs, and went back to where he hit the shot. He dropped two more balls and proceeded to make essentially the exact same shot with the exact same fantastic result with the other two clubs. When he was done, he asked the man if he still wanted to know which club he used.

It's good to learn new tools, but to be a great programmer, don't focus on the tools.

Happy coding!

Signup for my newsletter here.

Visit Us: thinkster.io | Facebook: @gothinkster | Twitter: @gothinkster

Beware of Vanilla JS

Joe Eames — Thu, 05 Nov 2020 15:23:02 +0000

I like to paint miniature figures for Star Wars (pics below for anyone who may be interested). It's about the geekiest of hobbies. The other day I was on a website buying custom bases for these figures. This site was out of the US, and the default currency was not US Dollars, but there was an option to switch the currency to US dollars so I did, and then I noticed this:

Look closely. What's going on here? That's not US dollars. US dollars show the currency before the number, and it uses a point not a comma to separate the integer from the decimal portion of a number. And how did this happen? Long story short, the developers decided to use a minimal amount of JavaScript and manage currency conversion and formatting themselves. And unfortunately, localization, like so many issues, has a lot of nuances that aren't obvious if you just learn a little. You have to dig deep and almost become an expert. A lot of currencies use commas and many use points, the placement of the symbol varies. Knowing these issues is just one of many things you have to worry about in building an app.

This is the value of front end frameworks. When they give you currency formatting tools, then someone has done all the research and you can reasonably trust that they'll get things right. In my free course on the Fundamentals of Angular we cover the currency pipe for formatting currencies, and it's surprising how many options there are for currencies. But that pipe means you don't have to worry about how to format currencies. Angular does it for you.

Ultimately this was a fairly minor issue, but nonetheless, it's indicative of something bigger. There's a fair amount of discussion of minimalism as our web apps initial download sizes get bigger and bigger and people push for better lighthouse scores.

So Do we need to use a framework for everything? No. And you can certainly find some library that handles currency for you. But that's only one issue. Even in a relatively simple issue, you'll have dozens of issues like that. Finding a different library for each issue is basically just piecing together a front end framework by hand.

This doesn't mean that every web application has to be built with React or another similar framework. But realize what you're giving up if you don't use a framework at all.

And in today's modern world there's a fair set of next generation minimalist frameworks you can use. Starting with Preact, which gives you 90% of React for 10% of the size, there's also Svelte, and recently AlpineJS and CrankJS.

You still need to learn JavaScript. It's the underpinnings of everything you will do on the web, which is a good time to point out our new course, JavaScript Fundamentals. If you're a pro user you can access that course now.

But just vanilla JS (hehe) by itself is a dangerous road to take.

As you make these decisions, being educated about the trade-offs can be very important. But the most important thing, as always, is to just build stuff and learn.

Happy coding!

Signup for my newsletter here.

Visit Us: thinkster.io | Facebook: @gothinkster | Twitter: @gothinkster

The Tricky Part of Validation Attributes in Angular

Joe Eames — Fri, 30 Oct 2020 17:40:29 +0000

In my free course on the Fundamentals of Angular, there are just over 2 hours of content on template-driven forms in Angular. One of the main parts of this is coverage of how to validate user input. This is an important part of any framework's forms handling.

But in Angular, there's a bit of an unmet promise when you learn about forms validation, and this can be confusing, so I'd like to just quickly cover the issue to help clear up any confusion you may encounter when doing forms validation in Angular.

When you first learn about forms validation, you quickly discover that there are several attributes you can add to an input control to validate that control. Angular's integration with this validation is simple and effective. It's a bit like magic.

Want to make sure that a field is required? Simply add the "required" attribute to the input element. Angular handles the rest for you. Want to make sure that a password has at least 8 characters? Use the minlength attribute. There's maxlength as well. And if you really have a tough validation problem, then there's the pattern attribute which uses regular expressions, and as they say, "now you have two problems" lol.

These attributes are part of the HTML5 spec, so using them is really natural. You're just leveraging the built-in parts of HTML and Angular is just making them five times more awesome.

So after learning these four attributes you may think "awesome, what other HTML validation attributes are there that I can use? Some quick Googling (or Binging?) will lead you to several more of these same validation attributes. There's min & max for dates & numbers, there's a step somewhat more obtuse attribute, and of course there's the good old type attribute on input elements. Such as type="email" and then suddenly you discover the unmet tacit promise of Angular validation.

Because these attributes do nothing with Angular validation. Nada. Squat.

At first, you may think that you're just not doing them right. But that's not it. They're not used by Angular. The framework simply doesn't utilize them. If you want to mimic them, you have to create custom validators yourself.

Now there is logic behind all this but ultimately it doesn't matter. You just need to know what is and is not supported. So here's a summary of useful information when doing validation in Angular's template-driven forms.

Supported Validation Attributes:

required
pattern
minlength
maxlength

Unsupported Validation Attributes:

type
min
max
step

So don't get confused if you run into this. It's just the way it is.

Happy coding!

Signup for my newsletter here.

Visit Us: thinkster.io | Facebook: @gothinkster | Twitter: @gothinkster

The Best 3 Angular Conference Talks this Year

Joe Eames — Thu, 15 Oct 2020 16:02:26 +0000

Earlier this year I was privileged to be able to help put on ng-conf Hardwired, a last-minute, seat of our pants scramble to turn an in-person conference into an online conference that was all duct tape and baling wire behind the scenes, but turned out great for the audience.

Anyway, I thought I'd just put out there that there were a few talks given at the conference that were truly epic and are absolute must-sees. These are pretty Angular-centric, FYI.

So here's my list in no particular order:

Farewell Entry Components by Yvonne Allen. Yvonne, who happens to be a Thinkster author, gave one of the most unique talks I've ever seen at a conference. It's not your typical lecture, but instead, a fake newscast where she discusses new features in Angular 9. It's as informative as it is entertaining. Go check it out.
Resilient Angular Testing - Jaw-Dropping Magic Tricks by the Magnificent Shai Rezniko. As the name implies, this is another one of those talks that has to be experienced to be understood. It's got great information on Angular unit testing and is again a fully entertaining talk.
How Ivy Will Improve Your Application Architecture. Manfred Steyer is one of the superheroes of Angular. His in-depth technical knowledge is nearly unsurpassed. This talk lays out some of the ways that the new Ivy engine will affect your Angular applications. Be sure to get rid of any distractions, this is a deep and esoteric talk.

So if you get some time, be sure to check out these talks.

Happy coding!

Signup for my newsletter here.

Visit Us: thinkster.io | Facebook: @gothinkster | Twitter: @gothinkster

The Most Misleading Part of Angular Forms Validation

Joe Eames — Thu, 08 Oct 2020 17:14:10 +0000

These attributes are part of the HTML5 spec, so using them is really natural. You're just leveraging the built-in parts of HTML and Angular is just making them five times more awesome.

So after learning these four attributes you may think "awesome, what other HTML validation attributes are there that I can use? Some quick Googling (or Binging?) will lead you to several more of these same validation attributes. There's min & max for dates & numbers, there's step a somewhat more obtuse attribute and of course, there's the good old type attribute on input elements. Such as type="email" and then suddenly you discover the unmet tacit promise of Angular validation.

Because these attributes do nothing with Angular validation. Nada. Squat.

Supported Validation Attributes:

required
pattern
minlength
maxlength

Unsupported Validation Attributes:

type
min
max
step

So don't get confused if you run into this. It's just the way it is.

Happy coding!

Signup for my newsletter here.
Visit Us: thinkster.io | Facebook: @gothinkster | Twitter: @gothinkster

What Should You Put in a Constructor vs ngOnInit in Angular

Joe Eames — Mon, 05 Oct 2020 15:55:33 +0000

One of the most confusing things when building an Angular component is deciding what to put in the constructor and what to put in the ngOnInit method. Both of these methods are used for similar purposes, both fire once at the beginning of the life of a component, so knowing what to put where can be troublesome. In this article, we'll break down when to use each method, and why, and what to put in them, and what NOT to put in them.

First, let's break down what each method does, and when it's fired.

The constructor is important in a component for two reasons. First, it's a lifecycle method, meaning it is called when the component is constructed, so, therefore, it has an important purpose in that if you want specific code to run at a certain time (during construction) then this is the right place to do it. Second, it's the place where you inject services into the component. It looks like this:

Note the use of TypeScript here. First we use the private keyword so that we retain a reference to our actor service. Second, we type the "actorService" variable with the "ActorService" type to let Angular know which service we want.

The ngOnInit method on the other hand, serves only as a lifecycle method, firing when a component is initialized.

Both construction and initialization take place at very similar times in the life of a component. And we often want certain kinds of code to run when our component is "created".

Some typical code to run here would be initializing internal state properties, loading data of which the component is in charge, usually via HTTP calls, calling initial methods on injected services, and starting up processes or calculations.

So should we do this during construction or initialization?

Construction happens when the JavaScript class is constructed. It's essentially the first thing that can happen to a class instance. Initialization, on the other hand, happens after that when the component is fully initialized. In essence, this means when Angular is done plugging all the pieces together.

Using this knowledge we can now look at best practices with these two methods, what to put in each, and what not to put in each.

Construction is first, but happens when the component isn't really a component yet. So therefore the constructor should only contain very basic simple code relating to basic initialization of the class. You will have the injected services, but that's about it. So typically we only put simple quick code such as state initialization. Although it's usually simpler to initialize those properties where they are declared if possible.

So do this:

Instead of this:

The only time to use the latter method is if you need access to an injected service when initializing state.

The ngOnInit method, on the other hand fires when the component is ready to be a component and ready to get to work. Therefore, just about all startup code should be placed here by default. Whether this is making HTTP calls, making calls to dependent services, or other similar items. We can even put our initial state initialization here and it's just fine. There's no drawback to putting it here instead of in the constructor.

So a quick rule of thumb honestly is to consider code in the constructor to be a code smell, and look at it closely to make sure that it shouldn't actually be in your ngOnInit method.

ngOnInit gotcha:

The ngOnInit method does have one gotcha. And that is that even if we change routes, if we're using the same component for both the previous and current route, then the ngOnInit method isn't fired again.

This commonly happens when looking at the details of an item in a list using a component as the detail view, for example, the details of an actor, and if that view has "next actor" and "previous actor" links. Then clicking those links to view the details of a different actor might change the route, but it doesn't cause the ngOnInit method to fire again. So be careful in this case.

For more on constructors and the ngOnInit method, check out my Fundamentals of Angular course, completely free, on Thinkster.io.

Happy coding!

Signup for my newsletter here.

Visit Us: thinkster.io | Facebook: @gothinkster | Twitter: @gothinkster

Arguments vs Parameters and The Rest Parameter

Joe Eames — Thu, 01 Oct 2020 21:30:13 +0000

Knowing the difference between arguments and parameters can be important.

But before we begin, just a quick note that our new course, Fundamentals of Angular, is out and completely free. That's right. 100% free. Nothing behind a paywall. This isn't a half course or anything. This is the whole enchilada. Go check it out.

And for a video version of this blog, click here.

I recently ran a quick little twitter poll to see if people, in general, knew the difference between parameters and arguments. The results of the poll were quite interesting.

Only 50% of people were confident with the difference between arguments and parameters, which makes this a good subject to review.

An argument is the value you pass into a function. A parameter is the name the function assigns to that value. That is the difference. Often times we use these two terms interchangeably, and most of the time the difference is unimportant. But it can matter, so learning the difference, and learning to use the appropriate term at the appropriate time can help with communication of all kinds.

In the above example, "itemName" and "quantity" are parameters, and "handSanitizer" and 300 are arguments.

This actually clues us in as to why we the arguments object in JavaScript is named arguments, and not parameters. Arguments are the values, not the names. The arguments object contains the values, but doesn't care about the names.

If you're not familiar with the arguments object, it's a global object that gives you information about the arguments used in the function call for the current context.

So in this example:

Notice how the arguments object was never created or referenced, it just exists. Inside that function, those three calls will log out "2", "Hand Sanitizer" and "300" respectively.

Now, why is there an arguments object when we have the named parameters anyway?

Well, JavaScript is just so loosey-goosey that it doesn't care if you pass it more arguments than there are parameters.

Now, look at the sentence I just typed. This is a GREAT example of why we need to understand the difference between arguments and parameters. If you use those two terms interchangeably, then the sentence makes no sense. But they're not the same thing. And understanding them lets us learn about things like the arguments object.

So continuing on, you can pass more arguments than there are parameters. Let's look at a case for this. Let's say we want a function that can receive a list of numbers and add them all up, but doesn't require that they're in an array, and can instead be passed in as separate arguments. Doing this with separate arguments would be impossible, and even if we do our best it's messy.

But with the arguments object, this is trivial. Since the arguments object only has the arguments that were already passed in, it's basically an array of numbers we just add up.

Unfortunately, arguments is only an array-like object, and not a full array, so we can't do things like reduce().

But thank you EcmaScript for coming to the rescue here. The Rest Parameter is a way to get the best of both worlds.

A rest parameter is a special parameter in a function signature (good thing we know what a parameter is vs. an argument) that is signified by three dots before it. It must be the very last parameter in a function signature. This parameter receives all the arguments that don't have named parameters already, and is an array of those arguments.

So our new AddEverythingUp method would look like this:

You can mix in named parameters (only before the rest parameter).

So for most uses, a rest parameter is preferred over the arguments object, and many developers now consider the arguments object to be a code smell.

And that's the rest parameter, and also arguments and parameters. Think you get it? Try this challenge and see if you can solve it!

How to learn five times faster

Here at Thinkster, we use educational science to teach you five times faster than just about anything else out there. How? With proper instruction based on educational principles and hands-on exercises, you will retain 75% to 90% of what you learn. Without these techniques, you only remember 7% to 15% of what you learn. That's why you can watch a video or a course or read a blog and feel like you need to watch a couple more before you really "get it".

You can see this in action in our courses. And you can get it for free in our Fundamentals of Angular course. Go check it out.

Happy Coding!

Signup for my newsletter here.

Visit Us: thinkster.io | Facebook: @gothinkster | Twitter: @gothinkster

Angular Lazy Loading Syntax Under the Hood

Joe Eames — Tue, 29 Sep 2020 01:47:18 +0000

Before we get started, I want to make sure that you were aware of the fact that our new Fundamentals of Angular course (my new course) is out and it is completely free! Seriously. The whole thing. All 41 hands-on exercises, all 13 hours, all free. Go through the whole course and never pay a dime (or ruble or shekel or whatever). Plus we got even crazier and we've made a way that you can actually get paid to go through the course.

Ok, on to the knowledge!

If you want a video version of this newsletter, you can find it here.

With complex front end applications, the size of an application often exceeds what is reasonable and creates a huge initial download. So one of the primary strategies for improving the performance of these types of applications is to cut down the initial download size, and deliver the rest of the application as needed, generally in a lazy-loaded manner.

In my new Fundamentals of Angular course, we cover lazy loading pieces of your Angular application. In this section, we learn how to create a lazy-loaded module and associated route using the loadChildren method in the route configuration. This is an example of how it looks:

This syntax is a bit different and may seem confusing at first glance, but if we take a minute and break it down there's a lot to learn from just this one piece of code.

First, the loadChildren property takes a callback function. This function receives no parameters. Inside this callback function, we call the import function.

This function isn't an Angular function, this is a basic part of JavaScript and the Browser. This allows the browser to dynamically download a file the moment this code is executed. If you're interested, I previously blogged about the difference between the static import statement and the dynamic import function. You can find that blog here.

Using the import function like this means that the moment the user attempts to navigate to this route (or any route containing this as the base part of the path), the referenced module is then downloaded.

In actuality, what the Angular build process creates is a bundle, and that bundle is what gets downloaded, but the bundle is an Angular module, so we can use the two terms interchangeably. This bundle is a single file, so when we call the import function, it downloads a single file which is the entire bundle and the entire module. The Angular build engine also includes anything the module directly references that wouldn't have been downloaded in the initial main download for the application.

Now the import function returns a promise. That promise resolves when the requested file is downloaded, so that way we can take an action when code gets downloaded. That of course is done in the .then() function. This function looks like this in our example:

This is an extremely important part of the whole process. Once the module (not just the module class, but everything that is part of the module) is downloaded, this function receives the downloaded code and returns the module class for Angular to process.

The fact that it's being returned is critical to understand. We can see that is what's happening by noticing that there are no curly braces.

That code is actually equivalent to this:

Without the curly braces in an arrow function like this, there is an implicit return statement. But if the code looked like this:

then there would be nothing getting returned from the promise.

When the module gets returned from that promise, the Angular framework receives that module, and then loads and processes it and all of its parts. Our lazy-loaded code is now part of the project as if it had been there from the start!

So here's a quick review/overview of the entire process:

We use the loadChildren key which triggers a function when that route is requested
The JavaScript import function downloads the indicated module bundle
After the download completes, the promise resolves, and we return the module class in the .then() function so that Angular can now begin loading and processing the module.

Breaking down a complex construct like this is useful for learning not only the framework we are using, but also JavaScript. I hope you got something out of this!

Happy coding!

Signup for my newsletter here.

Visit Us: thinkster.io | Facebook: @gothinkster | Twitter: @gothinkster

The Difference Between the Import function and the Import Statement

Joe Eames — Thu, 24 Sep 2020 16:00:35 +0000

In my new Fundamentals of Angular course that is being released later this week, I cover lazy loading with Angular feature modules. In the section on lazy loading, we encounter the import() function. One of the things that can be confusing about this function is how it compares to the more common import statement.

I've previously written about the import statement and how it can be confusing. If you want a deeper dive on that, check out my blog here.

Let's take a quick look at the import statement and the import function in JavaScript.

The import statement is what allows us to divide up our JavaScript into multiple files without using Script tags and ugly globals.

Generally, the import statement looks something like this and appears at the top of our files:

This statement is a static import. Whatever engine is processing our JavaScript to bundle up for delivery to the browser will crawl all the import statements we have in our files, and create one large bundle. In general, this is desirable. It allows for static analysis of our files, and advanced optimizations like tree shaking and dead code removal.

But it doesn't allow us to either delay the inclusion of some code into our client-side project, or delay the download and loading of some of our code.

As projects get bigger and more complex and we use larger and larger frameworks and more and more third-party tools, our initial bundle can get unreasonably large. So finding the parts of our application that aren't needed initially, and downloading them later can improve the initial performance of our application. And if the code is never needed, then we don't have to force the user to download it.

This functionality is enabled with the import function.

The import function uses quite a different syntax than the static import statement.

It looks like this:

Let's go over this syntax, and what it's doing.

First of all, the module path is probably the most likely place you'll get something messed up. Getting the path wrong is easy since the path has to make sense to the server. So correctly getting the path to the module set is really the biggest potential mistake. You can either give a complete path to the file, or you can give a relative path in which case the browser will assume your base URL from your current domain. Any import statement executed like this will show up in the network tab of your browser as a typical JavaScript request.

Once the module has been downloaded, you now have a handle to the module itself and can do whatever you want with it in the then callback function of the promise. Note that the downloaded module is immediately parsed and executed by the browser without you doing anything. So if the code has any side effects, you can't stop them from happening.

This is the mechanism used by many frameworks and libraries to download code on demand whenever needed.

We use XHR calls to gather data, but we use the dynamic import function to gather additional code our project may need.

The import function is used far less often than the static import statement, but it's still extremely useful to understand.

Happy coding!

Signup for my newsletter here.

Visit Us: thinkster.io | Facebook: @gothinkster | Twitter: @gothinkster