Meteor 1.6 and "Lazy Modules"


#1

I have some nuisance problems that lazy loading would probably fix, but I would first like to look at some best-practice examples or tutorials.

Any suggestions where I could find some?


#2

What you’re looking is dynamic-imports.

Here’s a quick example of how it works: https://github.com/msavin/dynamic-import-example


#3

Wow! Fast answer for early hours on a weekend morning! Thanks! Are you in Europe?
I’ll have look …


#4

Haha yep I’m in Europe


#5

Ok. I’m confused.

“Lazy Modules” is one of the highlights of the upcoming 1,6 release that Benjamin refers to In his blog post 2 weeks ago, “What’s coming in Meteor 1.6”.

Your example uses 1.5 from last July.

I quickly upgraded to 1.6 beta because my module handling is seriously klugy, but looking more closely at the blog post I notice that feature has status: planned.

Have I jumped the gun, or am I missing something here?


#6

There are two things here:

  1. The ability to do exact code splitting which is called dynamic imports. This would allow you to reduce the bundle size by splitting it using JS dynamic import statements and yes this was available in 1.5

  2. And “lazy module” which I think refers to making the import directory optional thus all your code will lazy imported and this planned for future releases

With 1.6 the main focus was upgrading Meteor node to version 8.


#7

Yeah. I’m beginning to see where I misunderstood.

What I’m hoping for is conditional loading, such that a module that won’t be loaded does not even need to be declared in package.json.

Am I expecting too much?


#8

The whole point of dynamic imports is to reduce the initial client bundle size so that your app load faster, especially on mobile, so that’s useful.

But I don’t understand what you mean by conditionally loading module (I’m assuming at the server) and what value does that bring?


#9

I belief he means dead code elimination, or not handling package trash in your code yourself. They’re looking to take care of that.


#10

Sorry. I was called away.

I have some core code and for certain cases, I want to override it with behavior from a module. So the idea is, if the module is present use it, otherwise use the core code.

Ideally, I would like to be able to plunk an isomorphic module, (with menu layout, default forms, ORM, etc, etc ) into my app directory and see it get picked up and used, with no package.json messiness or any other explicit configuration.


#11

That’s an interesting use case. If I understood correctly, it seems that your are looking at something more like meteor package based architecture then dynamic imports and lazy modules…


#12

For those cases, I’d try to use require("package") in a try/catch block, and define those packages as peerDependency in package.json.


#13

The dynamic import [e.g. import(file)] depends on a knowing where all modules are at compile time. This means you cannot use different files post compile with it :confused:

See: #9129, feature request 167, #8744 comment


#14

Yes, That’s what I had already found months ago, however I had been hoping that Node 8 and Meteor 1.6 would make it possible to do the sort of “plug’n play” I had in mind.

Instead, I have been experimenting with providing a null placeholder module for each actual module I might want to include. Those respect the definition of a working module but otherwise don’t do anything. I have a pre-build script that replaces a subset of dummy modules with the fleshed out modules I actually want to use in a given situation.

It’s kind of messy, still.

Thanks for those links, they’re exactly what I need to reaffirm what I had suspected was the case.