I'd like to host the TimeLineJS library on my Meteor app locally and not use the smart package because I need to fine tune it. I've tried declaring the createStoryJS function in the Meteor space like this in create Timeline.js. However, there are other dependencies (storyjs-embed.js, storyjs-embed-generator.js, storyjs-embed.js, and everything under locale) which rely on the document object on the browser. How can I ensure that Timeline.js is loaded in a template with all of its dependencies locally managed, while successfully accessing the window.document object?
Put all the files in client/compatibility in your app, such that the dependencies load first via Meteor’s load order (e.g. put dependencies in client/compatibility/lib, for example). That’s all you have to do: no script tags, no declaring anything. Initialize TimeLineJS within a template’s onRendered callback.
Related
I'm currently working on a package for Meteor that includes a build plugin. I need to access configurations from the settings file.
However Meteor.settings doesn't work (Meteor is not defined) and process.env.METEOR_SETTINGS also doesn't exist.
Is there any way for my plugin to access the settings file?
It appears that despite the documentation discussing the use of --settings, it doesn't work in a production environment, as often command line options are not available.
So the solution is to use environment variables, which are available only on the server.
server code, meteor methods:
eor methods
Meteor.methods({
getPJS: function() {
return process.env.PEERJS_SERVER;
},
client code
var PJS = Meteor.call("getPJS");
So you can make those environment variables available on the client if you need them.
I'm building a meteor package I noticed that in a package even if I put my code in server directory the code runs # the client . What's the pattern used in packages to separate code ? Should I rely only on wrapping the code with Meteor.isServer ? Is there a configuration for package.js ?
Packages do not rely on application level specific file structure responsible for conditional loading and load order, on the contrary you have to specify which files are loaded first and on which architecture.
You can do so using the Packages API, in particular use this :
https://docs.meteor.com/#/full/pack_addFiles
Package.onUse(function(api){
// ...
api.addFiles("server/server.js","server");
// ...
});
There is nothing preventing you to adopt the application file structure with client/server directories, just remember that it has no impact on actual file adding/loading control logic.
I am just starting with Meteor and working on an existing project. I am running into an issue with one of the packages(observatory-apollo) that's has the following line:
__meteor_bootstrap__.app.use Observatory.logger #TLog.useragent
It is complaining that __meteor_bootstrap__.app is undefined.
What is __meteor_boostrap__ exactly? I can't seem to find a description of what it is but from threads, people seem to know how to use it. I can only see it defined in boot.js, but it doesn't really tell me much...
Meteor uses connect npm module under the hood for various reasons, to serve static files, for example. __meteor_bootstrap__.app was the reference to connect app instance.
Before it was __meteor_bootstrap__.app but it changed couple of releases ago and became WebApp.connectHandlers object and is part of WebApp package.
WebApp is a standard package of Meteor, core package for building webapps. You don't usually need to add explicitly as it is a dependency of standard-app-packages.
Example of usage the connectHandlers is to inject connect middlewares in the same way as you would use any connect middleware (or some express middlewares, express is built on top of connect):
WebApp.connectHandlers
.use(connect.query())
.use(this._config.requestParser(bodyParser))
You can look at meteor-router Atmosphere package and take it as an example: https://github.com/tmeasday/meteor-router/blob/master/lib/router_server.js
More about connect: https://npmjs.org/package/connect
With the latest Meteor version 0.5.9 I've been experimenting with the appcache package, and really like its functionality.
I used meteor create --example leaderboard and then meteor add appcacheto test out the behaviour, and the page even loads when the server is not running at all! Super cool!
However, the database does not seem to be cached? When the server is not running
Players.find().fetch()
returns
[]
This is quite a showstopper for me, as I'm making a notes app where the notes need to be available offline as well. Am I missing something or is there an alternative method of getting database data when offline?
Look at the Ground:DB Package for this use. This package makes client side caches of subscribed collections.
https://atmospherejs.com/ground/db
Example of a collection that will get populated by Meteor subscriptions (subscribe call required separately)
localCollection = new Ground.Collection('mongoName');
Example of disconnected Collection (so you have to populate it yourself)
disconnectedCollection = new Ground.Collection('localName', {connection:null} );
The appcache package doesn't cache your data. See the docs:
The appcache package stores the static parts of a Meteor application (the client side Javascript, HTML, CSS, and images) in the browser's application cache.
[...]
(Note however that the appcache package by itself doesn't make data available offline: in an application loaded offline, a Meteor Collection will appear to be empty in the client until the Internet becomes available and the browser is able to establish a livedata connection).
At this point the appcache package is purely meant to improve loading speed of your app by caching static resources. See the meteor wiki:
The appcache package is only designed to cache static resources. As an "application" cache, it caches the resources needed by the application, including the HTML, CSS, Javascript and files published in the public/ directory.
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