So I’m using Meteor 1.3 with React and React-Router and I’m following the guidelines and all this by explicitly importing everything on an as-needed basis, including my node packages obviously. Though at times it can feel redundant and thereby the opposite of DRY coding, I have gone out of my way to enforce it on my team because the premise of explicit imports, aka code splitting, makes beautiful sense to me. Today, much to my surprise and somewhat horror, I looked over code that someone on our team wrote where he is defining a component and using velocity, velocity-animate and jquery without importing anything at all – much to my chagrin, it works without even a distant sign of error, assumably because I’m importing those packages elsewhere (to other components).
My questions:
1. Is there a way to actually code split and make all of these separate import statements worth my time? 2. Whose fault is this? Is it a general Meteor thing, is it react or react-router, etc.? 3. Am I right to assume that basically in my current app (and assumably all other Meteor 1.3 apps), imported node modules are added to some sort of global list and subsequent front-end imports are essentially redundant? 4. Assuming there isn’t a way to modify Meteor (or react/react-router) to “genuinely” code split, would I be all-the-wiser to essentially not repeat all of my imports for my front-end packages and import them once to let’s say ‘/imports/startup/client/index’ (I am using Meteor’s suggested application structure fyi)
Sorry for the length slash I’m the first to admit that maybe I’m missing something basic here…
No. They’re currently worth your time to help componentize your app.
It does support es6 imports. It doesn’t support code-splitting. Meteor doesn’t use webpack (though there is a package that can make it do that). So…blame Meteor?
If you don’t import something to the client and it’ not an atmosphere package, then it will not be added to the client bundle.
Keep doing it the way you’re doing it. Like I said in #1, it’s useful to add imports so that your code will be more modularized - which leads to better maintainability, more code-re-use and easier testing.
Thank you for the reply! I meant to mention in 3. “and subsequent front-end imports are essentially redundant?” so I will edit my post accordingly. Also, I totally got webpack and websockets mixed for one another so may edit my question there as well…
Given your reply, would you say that, for now, when it comes to client imports, they are essentially “optimistic” AKA training wheels for a future point when client-side import statements are actually code-split or at least the option is there? Also, is there a cost to importing the same package to the client a bunch of times in order to keep your code modular?
Depends on how important you think code-splitting is. I haven’t run into a need for it yet, though my app is not super massive yet. Imports are still great for all the reasons I mentioned.
I just thought that was the whole point. I agree that it’s up to me and such, and I do think it keeps your code modular, so those are the pros. My concern is that I can imagine importing a front-end package way down some component chain and having it be globally loaded to my app; finding and removing it (and also generally having an idea of what I’m actually specifically using on the front end) would perhaps be easier if I just manually maintained a list of global dependencies in a single file… Food for thought I guess.
Actually, this is the main benefit of imports - if you have a global list of dependencies, how do you even know what is using it? At least now you can search your codebase for from 'package-name' and find everything that is using a particular package. Before, it was a nightmare to identify which stuff is being used where.
I see, I hadn’t really considered that. I was under the impression it was so that nothing was available unless explicitly imported AKA to essentially code split, but what you’re saying does make sense. I do take what you’re saying especially seriously since it’s my understanding that you’re a Meteor celeb
Heh, thanks - but also make your own decisions about what you do and don’t like :] I can only tell you about how it works and why we did it the way we did!
I wish there were a way to turn off globals completely and force imports, but you can achieve something similar via linting: Code Style | Meteor Guide
The linter can check to make sure you never use a variable without importing it first.
Oh I def am already linting! What’s weird is on that component file it throws no errors but I wonder if it’s because a teammate who doesn’t use linting created the file??
Nice, I will check that out. Yeah on all other files it definitely barks at me if I use any variable or function etc that hasn’t been defined or imported to that file, it’s just particularly that file. Thanks by the way!
