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
Top comments (0)