Web Performance with Webpack Dynamic Code Splitting
Transcript from the "Dynamic Code Splitting" Lesson
>> Sean Larkin: I talked kind of about, I stopped here where we dove into actually how it works in the code. But things to remember, that I think are important, is that anytime you use a dynamic import, it's always returning a promise, right? And it's creating and putting the modules that you dynamically imported into a separate file.
[00:00:23] Now I wanna talk about dynamic code splitting. Dynamic, dynamic, I can't emphasize enough that this is not true dynamic loading, but this is kind of a trick. It's a little compiler trick. It's a heuristic. So let's take this code example that we see here. So we're using the dynamic input in the same way that we're familiar with, right?
[00:00:56] We assign a variable to a function that returns a dynamic import, but we're doing something a little bit different. This path is not fully static, right? There is a variable in here. And we're taking that variable from the function parameter and it's passed in. So, now when you use this code, you actually see that you can leverage global conditions at runtime to choose when to dynamically load something.
[00:01:31] Dynamically load something. So I call it dynamic code splitting cuz you can actually use runtime conditions to actually choose when to load something lazily. I was blown away cuz I was like, wow, how does this work? So I'm gonna break this down. So we know that we have a function that returns a dynamic import, but in this case there's two things that I want you to walk away with this technique.
[00:02:04] Is that there's two pieces that are really important. We have the expression, which is the dynamic piece. And we have a partial path, which is the static piece, right?
>> Sean Larkin: What we call this in our technical terms, in Webpack we call this a ContextModule. And I don't know why Tobias chose context as the name.
[00:02:32] Really, it's like directory. That's what we mean by context. The path, the directory. So let's say, given this example, we have a set of themes that are inside of a folder, right? And each of these has an individual kind of theme defined in an ES module or whatever.
[00:02:53] So, Webpack, what we're telling it to do, we're basically saying, hey, Webpack, take this partial path and find all the possible modules that can resolve in it and create individual bundles for them, right? Does that make sense so far? So it's not dynamic, it's still static. Everything that we're doing, we're creating these chunks at build time.
[00:03:18] So, dynamic, right? You can never do it with just a variable alone. In fact, I'll show you in a second when we will write an example like this. But I'll show, in fact, that we throw a warning and it doesn't really work when you try to use it with just a variable.
[00:03:41] And so you might be like, so when do we use this? Who here has to write AB tests, right? You probably all have to. Now here's the next question. Who here has to load both of their tests at runtime? Typically, when you're doing AB tests, you end up having to ship any scenario up front, right?
[00:04:04] You don't need to, but that's probably contributing to unused code. Because if you're only going through one scenario, you show me load the one UI piece for that scenario. And you can do it lazily.
>> Sean Larkin: Theming, just like you saw in that example, it's a great way. And it's just convenience, right?
[00:04:23] Because if you look back at this, we could write this code using just static, right? We would just have a lot more code to work with, right? We'd have to say get stylish theme equals the direct path, without a variable. Get whatever theme equals, it's kind of a convenience feature, but it also is really expressive, right?
[00:04:46] And it helps remove duplication. And it's just easier to wrap. For me, it's easier to do something like this.