In Meteor is there a way to include a js file in another js file.
Specifically, server side and most importantly at start up.
The use case I am running into is for complicated Meteor.startups where I need to load quite a bit of data to the mongodb into a variety of collections.
In order to have different test scripts I have to have more than one file each with duplicate data.
So, is there anyway to have say a boostrap.js file that calls Meteor.startup and then is able to load different files in order to load up the test data?
Or can this be done in a different way through some kind of object?
By design Meteor will automatically include all the javascript files in the the entire project (except in the public folder) but only segregate them between the server and client.
You could create objects in separate files and just use the functions or objects whenever you please, they should all be available at startup.
Try using my module loader made for use with Meteor. It's very similar to AMD: https://github.com/matb33/meteor-smd
Related
Per the Meteor docs, I'm trying to determine which special folder to place non-app assets (ex. Photoshop design PSDs) in, so that they still get checked into source control but don't get wrapped into the eventual client or server payloads.
It feels 'wrong' to use tests/ for this purpose but the docs suggest it has the desired behavior. Can private/ be used similarly, or will its contents always get added to the server bundle regardless of whether your app code registers any Assets? (Or is there a better place altogether to put such files?)
Consider a project structure like this:
/YourMeteorProject
/YourPSDFiles
file1.psd
file2.psd
...
/YourMeteorApp
/.meteor
/client
/server
...
You can launch your meteor app from within /YourMeteorApp. Files that are not part of your application, such as your PSD files, are kept outside of the application.
I have some code that is used on both the client and the server, that I need to be loaded before all code in server/ and client/
I tried to put the common code in lib/, but then I run into issues when I have code in client/lib and server/lib that depends on the code in lib/ to be defined when they load.
Here's an example of file load order from the Meteor documentation under the section File Load Order:
nav.html
main.html
client/lib/methods.js
client/lib/styles.js
lib/feature/styles.js
lib/collections.js
client/feature-y.js
feature-x.js
client/main.js
According to this example, files in client/lib/ get loaded before files in lib/.
I need the files in lib/ to load before the files in client/lib/. Is there any way to change this?
I'm putting my collection definitions in lib/, and my client subscriptions in client/lib. Organizing it like this makes sense to me because, my helpers in client/helpers.js depend on client/lib/subscriptions.js, and my subscriptions depend on the collections defined in lib/collections.js, and both the client and the server need the collection definitions, so I put them in lib/.
I found a clever solution.
I essentially renamed ./client/lib/ to ./client/deps/, which changed the load order to the following.
./lib/collections.js
./client/deps/subscriptions.js
./client/helpers.js
I need this order because my subscriptions depend on a collection being defined, and my helpers depend on subscriptions being defined.
The folder ./client/lib/ will always be loaded before ./lib/, but ./client/deps/ will be loaded after ./lib/ and before ./client/helpers.js, because ./client/deps/ is a deeper folder than ./client/, as per the Meteor documentation on File Load Order.
The docs on docs.meteor.com are very lacking for this check. I've seen elsewhere that it is useful for setting up helper functions in a Handlebars (and the new Spacebars?) JS. But where else would a Meteor.isClient check be required?
It's useful whenever you have shared code between the client and the server. For example, the default code that comes with any new meteor project puts all of the javascript into a single file. Template definitions won't work on the server, so they need to be wrapped within a Meteor.isClient check. Of course in a larger project, you can easily separate these sections into their respective /client and /server directories. However, you could still have utility functions, or methods defined in a shared directory. In those cases you may again find that some portions of the code only make sense when executed in one of the two environments.
TL;DR
They are critical for small apps where all of the code exists in a single file. Larger apps tend to use them only for things like meteor methods which can have a single definition but work differently depending on the environment.
I want to use web worker to play a sequence of sounds that depends on Meteor's Session variables. So I can't really put it in the public folder.
Does it I mean I must wrap it into a package in order to use web worker?
Meteor is based on connect, so, you can put the file worker.js outside the app folder (make it not loaded), then use your self-defining router
.use('/worker.js', FILEPATH).
The /public folder is not for scripts. Sounds like a client-side task – put it in the /client folder (maybe inside a Meteor.startup() function).
Copying a static website, i.e., HTML, CSS, JS is very simple.
Copying a dynamic website, i.e., is difficult due to the server-side scripts.
I'm concerned about cloning any meteor app as most of the server-side scripts are eliminated and the only thing which needs to be copied is the database, the schema can be easily obtained from the meteor live app and data can be easily scraped from the existing meteor app.
If a successful meteor app can be easily cloned, no one would prefer to develop an app on meteor.
Is there a way to stop cloning an existing meteor app?
Well, technically a meteor app can be cloned it depends on your directory/file structure & whether you're using it in development mode. If you're using one file and this sort of structure to seperate your code:
if(Meteor.isClient) {
}
if(Meteor.isServer) {
}
Because this file would be sent down to the client so someone can fetch it.
So it might be better to move to this structure
/client - Place stuff in Meteor.isClient in a new js file
/server - Place your server side code in a new js file
/public - Place other public folder stuff
So no one will see the server side scripts, so they can't clone the backend of your app.
Production mode/Dev mode
In addition if you run your Meteor app in 'production mode' the Javascript is packed, handlebars & handlebars templates are precompiled.
In my opinion, it might be actually harder to copy a Meteor app to the previous types of web apps because HTML is rendered on the client side, fetching the html files will actually get back empty html files, if you even prettify the large JS file still leaves back precompiled handlebars templates. In addition files are merged into one!
So thats when it comes to cloning it to another meteor app. Even if getting the client script is available (as with any other stack) there are even more hurdles with Meteor when it comes to replicating the server script:
DDP
Attempting to clone it to a PHP/Server side script stack might be even harder because POST/GET aren't even used, DDP is used instead.
Schema
Width regards to the schema, you can control what the client sees via Meteor.publish, so they won't actually see the whole schema