In my Meteor project, Can I have app/client/abc.js AND app/server/abc.js and expect meteor to handle them graciously?
Yes. File names in meteor are not currently meaningful apart from manipulating load order. See the structuring your app section of the docs.
Yes you can have abc.js in both client and server folders. However, /client/abc.js will be loaded only on client, whereas /server/abc.js will be loaded only on server.
Related
Meteor 1.5 was recently released, and it has... dynamic imports!
All the examples I see are for dynamically importing one file, and then running code for it. I'm curious if there is a way to dynamically import multiple files with one declaration?
Thanks. :)
Depends on what you mean by "import multiple files"…
Whenever you request a dynamic import, Meteor will fetch the required module and all its dependencies which are not already available in the browser cache.
On the contrary of classic HTTP request, the downloading is not parallelized, but goes through the already available Websocket. So all modules go through a pipe / queue.
If your code depends on multiple modules, you could simply write a "parent" module.
Or you could also aggregate your dynamic imports with Promise.all, since they return Promises.
Is it possible to use the h5ai "pretty" index UI on a CDN? I'm using Dreamhosts' DreamObjects and have it installed correctly (I've used it before on standard hosting sites). Am only getting an XML parse of the data back.
See it here: https://randassets.objects.cdn.dream.io/
Any thoughts? Thanks!
I guess what you would like to see is a pretty-looking list of files and directories on a web page, like a file browser to explore the content of your DreamObjects bucket. If that's the case, hi5ai would not work because from what I understand, hi5ai doesn't natively speak neither the S3 API nor the OpenStack Swift ones. hi5ai relies on a web server and a php interpreter, which are not provided by DreamObjects.
Maybe if you expand on your use case I can suggest you other tools you could use to browse your collection of files, something like ownCloud (and more specifically how to configure DreamObjects with ownCloud) or others.
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.
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
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